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SUMMARY 


I.  THE  TECHNICAL  PROBLEM 


In  pursuing  the  research  and  development  strategies  which  vara 
developed  In  previous  INCO,  INC.  contractual  efforts  regarding  the  evolvement 
of  an  Automated  Intelligence  Processes  Exercise  and  Review  System  (AIPERS) , 
the  several  technical  milestones  to  be  reached  have  been  factored  and  ini- 
tially addressed.  Previously,  exercise  control  and  tracking  functions  were 
provided  with  functional  specifications,  the  matter  of  post-exercise  critiques 
was  treated  in  detail  and  some  Initial  considerations  were  structured  with 
respect  to  the  incorporation  of  decision  Impact  analysis  In  the  control  func- 
tion for  automated  exercise  systems.  As  a result  of  those  past  efforts,  spe- 
cific areas  requiring  further  research  and  development  were  Identified;  work 
accomplished  on  the  present  contract  has  addressed  those  R&D  areas.  The  tech- 
nical problem  has  consisted  of  performing  the  necessary  analytical  and  design 
effort  to  complete  the  functional  specifications  for  all  AIPERS  nodules,  in- 
vestigate more  thoroughly  the  role  of  decision  Impact  analysis,  and  the  de- 
velopment of  the  means  to  demonstrate  the  exercise  system's  designed  features 
In  a Demonstration  Utility  Prototype. 


II.  GENERAL  METHODOLOGY 


In  researching  solutions  to  the  several  technical  problems  attendant 
to  the  development  of  automated  exercise  systems,  the  methodology  employed  was 
essentially  an  iteration  of  that  for  the  previous  contract  effort.  Each  con- 
tributor was  encouraged  to  independently  "brain-storm"  the  possible  paths  of 
development.  Subsequently,  in  shirt-sleeve  seminars,  the  members  of  the  de- 
velopment team  discussed  their  various  options,  and  from  such  presentations, 
compatible  design  approaches  were  selected.  The  design  characteristics  of 
each  module  or  task  performance  feature  were  thereby  settled  upon.  As  an 
example:  the  scenario's  key  events  were  first  Identified  and  the  necessary 

messages  were  written  and  sequenced.  Following  this  the  two  additional  design 
selections  were  performed  for  scenario  generation  using  a message  library  and 
for  scenario  processing.  After  the  development  of  anticipated  response  arrays 
for  key  events  was  completed,  enhancement  of  the  scenario  processor  was  possi- 
ble to  accommodate  the  arrays  so  that  they  could  be  viewed  by  the  Control 
Team.  Because  the  arrays  comprised  various  queries,  responses  to  anticipated 
queries  were  written  and  control  capabilities  were  created  to  activate  such 
responses. 

In  many  instances,  such  Joint  development  procedures  resulted  In 
Interim  solutions  which  required  refinement.  As  each  performance  characteris- 
tic was  settled  upon,  relevant  data  were  formalized  in  technical  memoranda. 
Later,  the  memoranda  formed  the  nucleus  for  the  contents  of  the  Final  Techni- 
cal Report. 


Ill 


III.  THE  TECHNICAL  REPORT 


The  results  of  the  R&D  effort  during  the  course  of  the  present  con- 
tract as  documented  in  the  Final  Technical  Report  are  included  in  four  dis- 
crete discussions.  The  first  two  address  the  remaining  logic  modules  of  the 
exercise  system  which  require  functional  design  specifications:  Scenario 

Generation  with  Automated  Assists,  and  Scenario  Processing.  These  two  sec- 
tions supplement  similar  sections  of  the  previous  Final  Technical  Report  which 
covered  Exercise  Controls  and  Exercise  Tracking. 

A third  chapter  in  the  report  discusses  some  methods  of  incorpora- 
ting the  results  of  decision  impact  analysis  (l.e.,  the  assessment  of  the 
effects  of  human  decision  upon  desired  exercise  vectors)  into  exercise  con- 
trols. Two  specific  methods,  sum  of  actions  taken  and  weighted  responses,  are 
used  in  conjunction  with  a number  of  scenario  elements  and  anticipated  arrays 
of  an  analyst's  responses.  Such  techniques  are  to  be  tested  using  the  AIPERS 
Demonstration  Utility  Prototype  (DUP). 

The  final  chapter  of  the  report  consists  of  a User's  Manual  for  the 
DUP.  The  manual  contains  the  necessary  instructions  for  use  of  the  DUP  in  a 
PDP  11/45,  AN/GYQ-21(V)  environment. 

At  this  time,  all  four  modules,  as  well  as  ancillary  performance 
units,  are  ready  for  system  design  specification,  coding  and  testing  for 
application  to  a PDP  11/45  environment.  The  sequence  of  total  exercise 
system  development  as  presently  envisaged  is  as  shown  on  Figure  1.  Work  to 
date  as  discussed  in  the  Technical  Report  is  within  the  dotted  lines. 


IV.  IMPLICATIONS  FOR  FURTHER  RESEARCH 


The  core  areas  for  further  research  attendant  to  full-scale  automa- 
ted exercise  development  or  generation  comprises  empirical  testing  of  the 
methods  for  utilizing  decision  impact  analysis,  response  arrays  and  the  com- 
plete integration  of  the  two  to  enhance  exercise  control  problems.  Such  re- 
search efforts  should  be  conducted  with  a scenario  expanded  from  that  presen- 
tly available  to  enable  the  testing  of  a full  spectrum  of  possible  decision 
analysis  impacts.  Other  research  which  is  desirable  is  focused  upon  the 
development  of  flexible,  highly  responsive  and  rapid  scenario  generation 
capabilities.  None  of  the  software  programs  essential  to  these  capabilities 
has  as  yet  been  written.  The  efficient  functioning  of  these  two  exercise 
performance  feature)  are  essential  to  effective  exercise  production. 


Sequence  of  AIPERS  Development  leeks 


V.  SPECIAL  COMMENTS 


The  test  and  evaluation  of  the  AIPERS  in  the  demonstration  utility 
prototype  environment  will  provide  the  vehicle  for  determining  the  effective- 
ness of  the  exercise  system's  concepts  and  software.  Additionally,  it  will 
provide  necessary  insights  into  the  requirements  for  adapting  AIPERS  to  and 
implementing  AIPERS  in  existing  or  developing  operational  I&W  systems. 

As  was  noted  in  the  previous  Technical  Report  Sumnary,  the  guide- 
lines ta  be  employed  in  the  final  phase  of  AIPERS  development  will  be  in  a 
format  to  facilitate  the  study  and  analysis  of  each  candidate  I&W  system  to 
be  exercised.  Because  each  I&W  system  is  unique  in  its  hardware  and  software 
configuration,  the  transfer  of  AIPERS  into  each  environment  will  necessarily 
require  careful  analysis.  If  AIPERS  is  piggy-backed  onto  the  operational 
I&W  system,  more  planning  and  a longer  and  more  involved  Implementation 
effort  will  be  required  than  that  of  a plug-in,  stand-alone  AIPERS  system. 
These  types  of  considerations  will  necessarily  be  addressed  in  the  guidelines 
for  integrating  AIPERS  into  a live  I&W  center: 

o System  hardware  characteristics 

o System  software,  to  include: 

- Interaction  with  the  operating  system 

- Interaction  with  operational  application  programs 

- Integration  of  AIPERS-unique  data  into  system  storage 
facilities 

- Intersystem  interaction  through  communication  facilities 

- Intersystem  storage  facilities 

o System  exercise  requirements 

- Single/multiple  exercise  capability  requirements 

- Intersystem  exercise  capability  requirements 

o Human  Interaction  media 

- Scenario  input  devices 

- Exercise  devices 

o Response  measurement  criteria 

o Reporting  content/format/medla 

o Scenario  development 

o Training  scenario 


vi 
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EVALUATION 


This  is  the  third  In  a aeries  of  technical  reports  addressed  to  the 
development  of  aids  to  facilitate  exercise  and  review  of  automated 
Intelligence  systems. 

A Demonstration  Utility  Prototype  (DUP)  is  currently  operational 
within  which  will  process  a scenario  of  up  to  100  events  so  one  in  two 
analysts  may  interact  with  8 resources  required  to  appropriately  respond 
to  the  scenario  stimulation  in  a simulated  I & W center.  Chapter  V 
is  the  users  manual. 

The  effort  is  of  value  to  exercise  the  many  intelligence  centers 
currently  being  given  automated  aids  and  netted  together,  enabling  realistic 
assessment  of  capabilities.  At  present  all  exercises  are  developed  manually 
and  are  consequently  extremely  cumbersome  and  expensive.  It  also  shows 
promise  as  a training  aid. 

Yuvt  uc.<  <*.  )// 

PATRICIA  M.  LANGENDORF 
Project  Engineer 
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CHAPTER  I 


INTRODUCTION  AND  SUMMARY 


A.  BACKGROUND 

This  volume  Is  the  third  in  a series  of  technical  reports 
prepared  by  INCO,  INC.,  which  define,  describe,  and  submit  interim 
design  specifications  by  function  for  the  components  of  the  Automated 
Intelligence  Processes  Exercise  and  Review  System  (AIPERS).  The 
initial  document  in  the  series  was  titled,  "Intelligence  Exercise 
Generation  Concept",  1 April  1974.  The  second  document  was  titled, 
"Exercise  Generation  Concept  Improvement:  Technical  Definitions  and 
a Development  Plan  for  an  Automated  Exercise  System,"  30  June  1975, 
and  was  subsequently  published  as  RADC-TR-75-252.  With  this  previous 
documentation,  the  feasibility  of  developing  an  automated  exercise 
system  was  established  and  a generalized  operational  concept  for 
AIPERS  was  produced.  To  place  the  current  effort  in  context  of  past 
endeavors, a concise  review  of  the  latter  follows.  In  the  two  Final 
Technical  Reports,  INCO,  INC.: 

o Detailed  the  Indications  and  warning  intelligence  processes 
products  and  interfaces  with  other  functional  areas  and 
Informational  resources. 

o Presented  the  objectives  of  exercises  and  exercise  systems 
derived  from  official  documentation. 

o Developed  methodologies  for  exercising  the  intelligence 
processes  on  a non-interference  basis. 

o Evolved  evaluation  criteria  for  an  automated  exercise 

generation  system  which  were  in  concert  with  the  defined 
objectives  of  exercises  and  exercise  systems. 

0 Identified  the  body  of  state-of-the-srt  technology  which 
is  applicable  to  the  design  and  structuring  of  the  AIPERS. 

o Highlighted  the  critical  areas  of  design  work  for  research 
and  development. 

o Prepared  a detailed  development  plan  and  an  Implementation 
schedule  for  the  exercise  system. 

o Provided  functional  design  specifications  for  exercise 
control  and  tracking  functions  and  the  methodology  for 
performing  tracking. 

o Articulated  initial  concepts  for  employing  decision  impact 
analysis  regarding  the  assessment  of  scenario  event 
stimulated  human  responses. 
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Accomplished  an  analysis  of  and  evolved  procedures  for 
exercise  operations  and  management  functions. 


Against  this  background  of  aggressive  research  and  development 
accomplishments,  work  on  the  current  contractual  effort  was  planned  to 
supplement  the  previous  ones  and  to  arrive  at  a point  where  the  exercise 
system  was  fully  described  and  where  a prototype  of  the  system  would  be 
demonstrable. 

B.  THE  CURRENT  EFFORT 

The  contents  of  this  volume  address  the  results  of  the 
contractual  effort  between  11  June  1975  and  10  June  1976.  During 
that  period,  the  remaining  functional  modules  of  the  exercise  system 
were  provided  descriptions  and  specifications.  Included  were  the 
Scenario  Generator  which  functions  in  the  pre-exercise  environment  with 
automated  assists  and  the  Scenario  Processor  which  provides  for  scenario 
element  release  and  for  the  interface  capabilities  between  the  various 
modules.  Additional  work  was  conducted  toward  the  technical  definition 
and  incorporation  of  decision  analysis  into  the  exercise  control 
function.  Further,  a Demonstration  Utility  Prototype  (DUP)  of  AIPERS 
was  developed  which  has  a number  of  the  full  scale  exercise  system's 
atrlbutes.  The  DUP  will  process  a scenario  of  up  to  100  events  so  that 
one  or  two  analysts  may  interact  with  eight  resources  required  to  appro- 
priately respond  to  the  scenario  stimulations  in  a simulated  I&W  center. 
Automated  exercise  controls  are  provided  which  enable  a "Control  Team" 
at  a separate  CRT  terminal  to  Interrupt  the  exercise,  accelerate  the 
release  of  the  scenario,  inject  ad  hoc  messages  into  the  Scenario 
Processor,  change  event  time  tags  and  simulate  other  addressees  of  the 
analyst/ player . Also  an  Exercise  Tracker  is  provided  which  will  log  all 
messages  processed,  all  Control  Team  actions  and  analyst's  responses. 
Tracker  print  outs  will  enhance  post-exercise  critique  procedures 
greatly.  A schema  of  the  DUP  is  presented  at  Figure  1-1  which  illus- 
trates the  interfaces  designed  into  it.  Figure  1-2  is  a schema  of  the 
actual  automated  exercise  system.  Similarities  and  differences  of  the 
two  may  be  examined  from  comparisons  of  the  schematics. 

C . SPECIFIC  ACCOMPLISHMENTS 

With  the  publication  of  this  document,  the  several  modules 
of  AIPERS  have  been  readied  for  system  design  specification,  coding 
and  testing. 

1.  Scenario  Generation  with  Automated  Assists 

Scenario  Generator  techniques  have  been  identified  and 
described  in  detail.  The  AIPERS  Scenario  Generator  will  take 
advantage  of  a Message  Library  of  pre-stored,  expandable  event 
descriptions  or  messages  which  may  be  retrieved  for  review  at 
a CRT,  edited  if  desired  and  reassigned  to  the  scenario  being 
compiled.  The  detailed  functional  specifications  for  this 
module  of  AIPERS  are  provided  in  Chapter  II  of  this  document. 
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2.  Scenario  Processor 


Scenario  Processor  performance  characteristics  and 
interfaces  have  been  defined  and  specified.  The  Scenario 
Processor  acts  as  a master  regulator  of  exercise  activities 
and  provides  the  medium  whereby  the  Control  element  may 
intercede  into  exercise  progression.  This  module  calls  up 
event  descriptors  or  messages  according  to  their  pre-set 
time  tags  and  sends  them  to  the  analyst's  CRT  for  review. 

Ad  hoc  Inputs  to  the  exercise  by  the  Control  Team  are  also 
admitted  by  the  Scenario  Processor.  Chapter  III  of  this 
document  includes  the  detailed  functional  specifications 
for  the  module. 


3.  Decision  Impact  Analysis 

The  role  of  decision  impact  analysis  in  the  functions 
of  an  exercise  was  Investigated  intensively.  Using  some  of 
the  concepts  developed  in  a previous  INCO,  INC.  Technical 
Report,  quantification  techniques  were  explored.  The  objective 
of  quantification  was  to  generate  an  error  signal  to  the  Control 
Team  whenever  the  exercise's  progression  become  skewed  from 
the  desired  goals.  Introducing  decision  impact  analysis  into 
the  Demonstration  Utility  Prototype  during  scenario  processing 
will  enable  the  proving  out  of  the  various  findings  to  date. 
Chapter  IV  of  this  document  comprises  technical  discussions 
of  approaches  and  findings  relating  to  decision  Impact  analysis. 

4.  Demonstration  Utility  Prototype  of  AIPERS 

The  final  Chapter  of  this  document  consists  of  a User's 
Manual  for  the  prototype.  The  manual  is  a revised  and  refined 
version  of  that  originally  provided  RADC  under  CDRL  item 
A003.  Following  the  instructions  and  routines  prescribed  in 
the  manual  will  enable  those  with  only  rudimentary  understanding 
of  hardware/ software  functioning  to  perform  or  operate  the  DUP 
for  a running  scenario  on  the  PDP-11/45. 
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Figure  1-2.  Schema  for  the  Automated  Intelligence  Processes 
Exercise  and  Review  System 


CHAPTER  II 


FUNCTIONAL  SPECIFICATIONS 
FOR  SCENARIO  GENERATION  WITH  AUTOMATED  ASSISTS 


A.  INTRODUCTION 

Scenario  generation  procedures  presently  employed  within  the  DoD 
intelligence  community  are  laborious  and  time  consuming.  Each  scenario 
for  an  exercise  is  generally  prepared  from  the  very  beginning,  and  is  pre- 
pared entirely  by  hand.  Also,  once  a scenario  is  produced,  it  is  only 
with  the  greatest  difficulty  that  it  may  be  altered  to  be  used  in  a varied 
scenario  situation.  The  primary  objectives  of  AIPERS  scenario  generation 
techniques  are  to  afford  the  scenario  writer  a significantly  enhanced 
capability  in  terms  of  speed,  flexibility  and  realism.  These  objectives 
will  be  satisfied  by  building  and  maintaining  an  automated  library  of 
messages  for  use  in  constructing  scenarios,  and  by  providing  computerized 
assistance  for  those  steps  of  scenario  generation  which  lend  themselves 
to  automation. 

The  remaining  sections  of  this  chapter  address  the  procedures 
required  to  generate  a scenario  for  an  AIPERS  exercise;  functional  speci- 
fications for  the  creation  and  maintenance  of  a library  of  scenario  messages 
and  functional  specifications  for  the  automated  portions  of  AIPERS  scenario 
generation. 

B.  AIPERS  SCENARIO  GENERATION  PROCEDURES 

The  steps  involved  in  generating  a scenario  for  use  by  the  AIPERS 
are  similar  to  those  currently  followed  by  scenario  writers  in  the  DoD 
intelligence  community.  These  steps  are: 

o Formulate  the  exercise  objectives 

o Produce  a narrative  or  statement  of  a situation, 
context,  or  environment  for  the  exercise 

o Define  principal  events  within  the  situation 

o Select  and/or  build  messages  which  develop  each 

event,  as  well  as  messages  which  merely  add  to 
the  bulk  of  traffic  to  be  processed 

o Time  sequence  all  message  traffic 
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o Predict  analyst's/participant's  responses  to  key 
events 

o Build  the  scenario  data  base  and  message  time  list 
for  input  to  the  AIPERS  Scenario  Processor. 

Each  of  these  steps  is  discussed  in  more  detail  in  the  ensuing  subsections. 

1.  Formulate  the  Exercise  Objectives 

The  first  step  in  generating  a scenario  for  an  AIPERS  exercise 
is  to  define  the  objectives  of  the  exercise:  that  is,  to  enum- 

erate exactly  which  aspects  of  the  l&W  (or  other  functional  area) 
center  operation  are  to  be  exercised  as  well  as  the  desired 
outcome  of  the  exercise.  These  pre-exercise  formulated  objectives 
are  the  determinants  of  the  specific  orientation  and  construction 
of  the  scenario  to  be  generated.  In  an  earlier  document  pre- 
pared by  INCO,  INC. , entitled  Intelligence  Exercise  Generation 
Concept  (Final  Report,  F30602-73-C-0340) , a variety 

of  such  objectives  were  identified  which  are  compatible  with 
the  design  of  the  Automated  Intelligence  Exercise  and  Review 
System  (AIPERS). 

2.  Define  the  Scenario  Situation 

Once  the  exercise  objectives  have  been  clearly  stated,  the 
next  step  is  to  define  a situation,  context,  or  environment 
for  the  exercise,  which,  when  the  scenario  is  constructed  and 
the  exercise  is  run,  will  allow  the  stated  objectives  to  be 
achieved.  A narrative  setting  must  be  produced  for  each 
scenario  that  is  constructed  in  order  that  participating  I&W 
analysts  may  have  a context  in  which  to  view  the  information 
contained  in  the  scenario  messages. 

3.  Enumerate  the  Principal  Exercise  Events 

Once  the  setting  for  the  scenario  has  been  written,* the 
scenario  writer  must  select  the  principal  events  about  which 
messages  may  be  "clustered"  in  order  to  fully  develop  the 
event.  The  collection  of  these  principal  events  should  form 
the  substance  of  the  exercise  situation,  context,  or  environment. 

4.  Collect  the  Scenario  Messages 

Once  the  exercise  objectives  are  defined,  the  scenario 
narrative  is  produced,  and  the  principal  scenario  events  are 
defined,  the  building  of  the  scenario  message  traffic  can 
commence.  This  step  of  AIPERS  scenario  generation  will  be 


automated,  and  will  be  supported  by  a computerized  data  base 
of  scenario  messages. 


a.  The  Message  Library 


The  objective  of  developing  a library  of  messages  is  to 
enable  that  any  particular  message — prepared  originally  for 
a specific  scenario — may  be  called  up  by  a key  word  index, 
examined  by  the  scenario  writer  for  applicability,  edited 
to  conform  to  the  situation  of  the  new  scenario,  and 
filed  on  disk  in  the  scenario  data  base.  For  example: 
were  a new  scenario  being  developed  which  contained  ref- 
erences to  a low-level  confrontation  between  the  Republics 
of  the  Philippines  and  Indonesia,  although  no  messages 
are  in  storage  regarding  that  political  problem  of  sover- 
eignty, the  key  words  "sea",  "political"  and  "sovereignty" 
might  be  used  to  retrieve  the  following  message  which 
had  been  prepared  for  a past  exercise: 

In  a communique  released  this  date,  the  foreign 
Ministry  of  the  Republic  of  China  has  reaffirmed 
its  stand  with  respect  to  ownership  of  the  Pescadores 
Island  Group  and  the  inter-island  waters,  in  addi- 
tion to  unidentified  limits  seaward  from  each  island. 

It  was  further  stated  that  the  Republic  of  China 
Government  would  consider  the  licensing  of  fishing 
vessels  to  enter  those  waters.  (UPI) 

By  identifying  the  words  "Pescadores  Island  Group"  and 
"China",  they  may  be  edited  to  refer  to  an  island  group 
in  the  Celebes  Sea  between  the  two  nations  in  the  new 
scenario  to  render  it  applicable.  The  time  saved  in 
producing  this  single  message  is  readily  apparent. 

b.  The  Key  Word  Index 

Major  categories  of  indices  must,  first  be  selected. 
Because  the  location  of  an  event  in  a message  will  un- 
doubtedly prove  to  be  more  easily  altered  (edited)  at 
a CRT  than  the  nature  of  the  event  itself,  place  names 
appear  to  be  less  suitable  as  a first-order  index. 

Persuing  a comparison  of  other  options,  a "most-probable 
to  succeed"  choice  may  be  that  of  (1)  land  (2)  sea 
(3)  air.  Two  of  the  categories  inherently  narrow  the 
possibilities  of  geographical  location  as  bonus  attri- 
butes. As  an  initial  hierarchical  structure  of  key  words 
for  message  retrieval,  the  array  subsequently  provided 
is  suggested. 
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c.  The  Key  Word  Hierarchy 
The  Array 


I. 

Land 

A. 

Economic 

II. 

Sea 

B. 

Political 

III. 

Air 

C. 

Military 

D. 

Scientific/Technological  R&D. 

The  third  level  of  the  hierarchy  comprises  a variety 
of  subject  categories  for  each  of  the  preceding  ones  (A-D). 
The  economic  heading  is  broken  down  thusly: 


Economic 

1. 

Trade 

8. 

Agriculture 

2. 

Fishing 

9. 

Planning 

3. 

Mining 

10. 

Seizures  (Expropriations) 

4. 

Transportation 

11. 

Disasters  (Earthquakes, 

5. 

Services 

Weather) 

6. 

Financial 

12. 

Assessments 

7. 

Conferences 

13. 

Agreements 

The  political  heading  is  subdivided: 
B.  Political 


1. 

Coup  d'Etat 

10. 

Seizures 

2. 

Assassinations 

11. 

Disasters 

3. 

Elections 

12. 

Disturbances 

4. 

Sovereignty 

13. 

Censorship 

5. 

Territory 

14. 

Personalities 

6. 

Conferences 

15. 

Assessments 

7. 

Diplomatic 

16. 

Propaganda 

8. 

Appointments 

17. 

Announcements 

9. 

Defections 

18. 

Agreements 

The  military  heading  is  subdivided: 
C.  Military 


1. 

OB 

Long  Rng  Air 

8. 

OB  Nav  Surf. 

2. 

OB 

Tac  Air 

9. 

OB  Nav  Submarine 

3. 

OB 

SSM 

10. 

OB  Nav  Air 

4. 

OB 

SAM 

11. 

OB  Nav  Missiles 

5. 

OB 

ASM 

12. 

OB  Other 

6. 

OB 

Other  Air 

13. 

Alerts 

7. 

OB 

GRND 

14. 

Movements 

* 


15. 

Insurgence 

24. 

Intell  Coll. 

16. 

Equipment 

25. 

ELINT 

17. 

Conscription 

26. 

NSOC 

18. 

Personnel 

27. 

NOSIC 

19. 

Planning 

28. 

DIPOLES 

20. 

Personality 

29. 

IRDHS 

21. 

Environment 

30. 

Seizures,  Incidents 

22. 

Assessments 

31. 

General  Operations 

23. 

Recce  Opns. 

32. 

Agreements 

The  scientific/ technological,  R&D  heading  is  subdivided: 
D.  Scientific/technological,  R&D 


1. 

Facilities 

5. 

Planning 

2. 

Equipment 

6. 

Conferences 

3. 

4. 

Events 

Personality 

7. 

Assessments 

d.  Messages  Not  Yet  in  the  Library 

It  is  not  contemplated  that  there  will  always  be  a 
suitable  message  in  the  library  for  adaptation  to  a new 
scenario;  however,  the  availability  of  such  a message 
any  significant  part  of  the  time  will  conserve  great 
amounts  of  generation  effort.  In  those  cases  when  a 
message  is  not  available,  a new  message  can  be  generated 
and  added  to  the  scenario  data  base.  All  such  new  messages 
will  be  added  to  the  message  library.  Thus,  successive 
efforts  will  continue  to  enhance  the  scenario  message 
library. 

e.  Scenario  Message  Hard  Copy  Production 

Once  all  messages  for  the  scenario  have  been  selected, 
it  will  be  necessary  to  provide  a hard  copy  of  these 
messages  for  the  further  scenario  generation  steps.  This 
will  be  provided  by  copying  the  disk-resident  scenario 
data  base  to  a line  printer. 

5.  Time  Sequence  the  Message  Traffic 

Once  the  data  base  of  scenario  messages  has  been  built,  the 
next  step  of  scenario  generation  is  to  time  sequence  the  message 
traffic  for  delivery  to  the  I&W  center  host  computer  during 
the  exercise.  This  is  done  by  assigning  each  message  a "time 
tag:"  the  value  in  hours,  minutes,  and  seconds  from  the 
beginning  of  the  exercise  that  the  message  is  to  be  delivered 
to  the  analyst/player 's  CRT. 


6. 


Predict  Analyst's  Responses 
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Once  all  message  traffic  has  been  selected  and  time- 
sequenced,  it  is  then  possible  to  predict  analyst's  reactions 
to  discrete  messages  or  groups  of  messages  during  a specific 
time  frame  in  the  exercise.  The  scenario  writer  must  deter- 
mine which  scenario  messages  represent  key  events  n d must 
furnish  possible  responses  (analyst's  actions)  with  assigned 
values  for  these  responses.  See  Chapter  IV  of  this  document 
for  more  information  concerning  anticipated  analyst's  responses 
and  their  use  in  the  AIPERS  exercise. 

7.  Build  the  Scenario  Data  Base  and  Message  Time  List 

Tliis  final  step  of  AIPERS  scenario  generation  is  automated, 
and  allows  the  scenario  generation  routines  to  build  the  input 
to  the  AIPERS  Scenario  Processor.  During  this  phase  of  the 
process,  the  assigned  time  tags  for  each  scenario  message  are 
entered  into  the  Message  Time  List  file,  and  the  anticipated 
analyst's  responses  to  the  key  events  are  formatted  into  data 
records  which  are  stored  into  the  scenario  data  base.  Once 
this  final  step  of  scenario  generation  is  completed,  all 
necessary  inputs  to  the  AIPERS  exercise  (the  scenario  data  base 
and  the  Message  Time  List)  will  be  available,  on  disk,  for  use 
by  the  Scenario  Processor. 

C.  FUNCTIONAL  SPECIFICATIONS  FOR  THE  SCENARIO  MESSAGE  LIBRARY 

In  the  preceding  section,  the  concept  for  maintaining  a library 
of  messages  catalogued  under  a specific  key  word  hierarchy  as  a scenario 
generator  tool  was  outlined  in  general  terms.  This  section  introduces 
specific  design  considerations  relating  to  the  structure  of  the  Message 
Library  and  the  Key  Word  Index  hierarchy  on  a mass  storage  device,  and 
relating  to  the  processing  requirements  for  creation  and  maintenance  of 
such  a library. 

1.  Message  Library  Storage  Structures 

It  has  been  determined  that  the  Message  Library  and  associated 
Key  Word  Index  adapts  well  to  a hierarchical  (tree)  file  struc- 
ture and  that  it  will  be  convenient  to  make  use  of  the  specific 
tree-structuring  method  employed  by  the  TOSS  Information  Manage- 
ment System  (TIMS)  to  build,  maintain,  and  gain  access  to  the 
Library  on  disk. 
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A tree  structure  corresponds  to  the  hierarchic  seg- 
mentation of  a dictionary.  The  highest-level  dictionary  points 
to  a second-level  dictionary,  and  so  on,  until  the  bottom-level 
dictionary  points  to  information  records.  The  application  of 
the  tree  for  the  Key  Word  Index  requires  a three-level  "dic- 
tionary" with  a fourth  level  composed  of  message  records.  A 
"set"  of  level-four  records  will  consist  of  pointers  to  all  of 
those  messages  referred  to  by  a specific  3-key  index.  TIMS 
allows  storage  of  the  messages  themselves  In  the  same  physical 
file  as  the  index,  separating  index-record  blocks  from  message- 
record  blocks;  alternatively,  messages  may  be  stored  in  a 
separate  file  and  their  addresses  stored  as  level-four  data 
in  the  Key  Word  Index.  The  former  scheme  provides  a slight 
edge  in  retrieval  time,  while  the  latter  decreases  the  storage 
required  when  single  messages  are  referenced  by  more  than  one 
3-key  index. 

Relating  the  selected  tree  structure  to  the  key  word  hier- 
archy described  in  the  previous  section,  there  are  category  de- 
scriptors at  three  levels,  with  external  (user)  access  provided 
via  a 3-key  index  consisting  of  a Roman  numeral  (level  1),  an 
alphabetic  character  (level  2),  and  an  Arabic  numeral  (level  3). 
Note  that  one  additional  category  has  been  added:  No  Category. 

This  is  to  accept  new  messages  input  to  the  library  from  a 
scenario  writer  during  scenario  generation.  The  following 
categories  are  suggested: 


Level 

1 Keys 

I. 

Land 

II. 

Sea 

III. 

Air 

IV. 

No  Category 

Level 

2 Keys 

Under  level  1 categories  I,  II,  and  III  (Land,  Sea,  and  Air) 

A.  Economic  C.  Military 

B.  Political  D.  Scientific/Technlogical,  R&D 

Under  level  1 category  IV  (No  Category) : 

E.  No  Category 
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1. 

Trade 

8. 

Agriculture 

2. 

Fishing 

9. 

Planning 

3. 

Mining 

10. 

Seizures 

4. 

Transportation 

11. 

Disasters 

5. 

Services 

12. 

Assessments 

6. 

Financ lal 

13. 

Agreements 

7. 

Conferences 

Under  level  2 Category 

B (Political) 

1. 

Coup  d'  Etat 

10. 

Seizures 

2. 

Assassinations 

11. 

Disasters 

3. 

Elections 

12. 

Disturbances 

4. 

Sovereignty 

13. 

Censorship 

5. 

Territory 

14. 

Personalities 

6. 

Conferences 

15. 

Assessments 

7. 

Diplomatic 

16. 

Propaganda 

8. 

Appointments 

17. 

Announcements 

9. 

Defections 

18. 

Agreements 

Under  level  2 Category 

C (Military): 

1. 

OB  Long  Rng.  Air 

17. 

Conscription 

2. 

OB  Tac  Air 

18. 

Personnel 

3. 

OB  SSM 

19. 

Planning 

4. 

OB  SAM 

20. 

Personality 

5. 

OB  ASM 

21. 

Environment 

6. 

OB  Other  Air 

22. 

Assessments 

7. 

OB  GRND 

23. 

Recce  Opns. 

8. 

OB  Nav  Surf. 

24. 

Intell  Coll. 

9. 

OB  Nav  Submarine 

25. 

ELINT 

10. 

OB  Nav  Air 

26. 

NSOC 

11. 

OB  Nav  Missiles 

27. 

NOSIC 

12. 

OB  Other 

28. 

DIPOLES 

13. 

Alerts 

29. 

IRDHS 

14. 

Movements 

30. 

Seizures,  Incidents 

15. 

Insurgency 

31. 

General  Operations 

16. 

Equipment 

32. 

Agreements 

Under  level  2 Category 

D (Scientific/Technological 

1. 

Facilities 

5. 

Planning 

2. 

Equipment 

6. 

Conferences 

3. 

Events 

7. 

Assessments 

4. 

Personality 

Under  level  2 Category  E (No  Category) 

1.  No  Category  (For  level  1 Category  IV  only) 
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2.  Message  Library  Creation  and  Maintenance 

Computer  programs  must  be  developed  for  the  creation  and 
maintenance  of  the  Message  Library  and  Key  Word  Hierarchic  Index 
on  disk.  Such  programs  must  perform  the  functions  of  adding 
messages  to  the  library,  refiling  messages  under  different 
categories,  deleting  messages  from  the  library,  and  publishing 
subsets  of  the  library  for  review.  Each  of  these  functions 
is  specified  in  more  detail  in  the  following  subsections.  It 
should  be  noted  that  the  function  of  library  maintenance  is 
currently  viewed  as  a computerized  batch  stream  job  rather 
than  an  on-line,  interactive  function. 

a.  Adding  Messages  to  the  Library 

The  function  of  adding  messages  to  the  Message  Library 
and  Key  Word  Index  is  performed  by  two  separate  AIPERS 
Scenario  Generation  components.  The  addition  of  messages 
created  during  scenario  generation  steps  by  the  scenario 
writer  will  be  discussed  in  a later  section. 

\ 

The  procedure  for  introducing  a message  into  the 
Message  Library  and  cataloguing  it  in  the  Key  Word  Index 
involves  the  following  steps: 

(1)  Accept  message  text  input  from  the  batch  input 
stream  and  store  it  in  the  Message  Library  under  a 
unique  identifier. 

(2)  Accept  a three-key  index  under  which  the  message 
is  to  be  catalogued. 

(3)  Search  level  1 of  the  index  file  for  the  level-1  key. 

(A)  Search  only  the  subset  of  level  2 of  the  index  file 
which  is  subordinate  to  the  found  key  on  level  1 for 
the  level-2  key. 

(5)  Search  only  the  subset  of  level  3 of  the  index  file 
which  is  subordinate  to  the  found  key  on  level  2 for 
the  level  3 key. 

(6)  Store  the  unique  message  identifier  into  message 
set  related  to  the  found  key  on  level  3. 
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(7)  Return  to  step  (2) , repeating  until  the  message 
has  been  completely  catalogued. 

(8)  Store  the  list  of  categories,  under  which  the 
message  has  been  filed, as  a descriptor  record  to  the 
message  record  in  the  Message  Library. 

(9)  Update  the  message  identifier  to  reflect  the 
next  available  unique  message  ID. 

(10)  Return  to  step  (1),  repeating  until  all  messages 
have  been  entered  into  the  library. 

The  processing  to  perform  each  Iteration  of  steps 
(3),  (4),  (5),  and  (6)  is  accomplished  automatically  by 
calling  TIMS.  The  remaining  processing  steps  must  be 
performed  by  the  message  addition  program  Itself. 

b.  Deleting  Messages  From  the  Library 

The  procedure  for  deleting  superfluous  messages  from 
the  Message  Library  and  the  Key  Word  Index  involves  the 
following  steps: 

(1)  Accept  the  unique  message  identifier  of  the  message 
to  be  deleted  from  the  batch  input  stream. 

(2)  Read  the  descriptor  record  for  the  specified  message, 
which  contains  the  categories  under  which  the  message 

is  referenced,  in  from  the  Message  Library. 

(3)  Obtain  a three-level  key  under  which  the  message 
is  filed. 

(4)  Search  level  1 of  the  index  file  for  the  level-1  key. 

(3)  Search  only  the  subset  of  level  2 (in  the  index 
file)  which  is  subordinate  to  the  found  key  on  level  1 
for  the  level-2  key. 

(6)  Search  only  the  subset  of  level  2 (in  the  index 
file)  which  is  subordinate  to  the  found  key  on  level  2 
for  the  level- 3 key. 

(7)  Delete  the  reference  to  the  specified  message  from 
the  message  set  related  to  the  found  key  on  level  3. 
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(8)  Return  to  step  (3)  repeating  until  all  ref- 
erences to  the  message  have  been  deleted  from  the 
index  file. 

(9)  Delete  the  message  record  and  message  descriptor 
record  from  the  Message  Library  file. 

(10)  Return  to  step  (1),  repeating  until  all  messages 
to  be  deleted  have  been  processed. 

The  processing  to  perform  each  interation  of  steps  (2), 

(4),  (5)v  (6),  (7),  and  (9)  is  accomplished  automatically 
by  calling  TIMS.  The  remaining  processing  steps  must  be 
performed  by  the  message  deletion  module  itself. 

c.  Refiling  Messages  Under  Different  Categories 

It  is  necessary  to  provide  the  capability  to  refile  messages 
under  different  categories  in  the  Key  Word  Hierarchical  Index. 
Specifically,  the  ability  to  add  a category  reference,  to  delete 
a category  reference,  and  the  ability  to  move  a message  reference 
from  one  category  to  another  must  be  accommodated. 

To  add  a category  referen  e to  a message,  the  following 
processing  steps  are  required: 

(1)  Obtain  the  message  identifier  and  the  new  three-level 
key  under  which  it  is  to  be  referenced  from  the  batch  input 
stream. 

(2)  Search  level  1 of  the  index  file  for  the  level  1 key. 

(3)  Search  only  the  subset  of  level  2 (of  the  index  file) 

which  is  subordinate  to  the  found  key  on  level  1 for  the 

level-2  key. 

(4)  Search  only  the  subset  of  level  3 (of  the  iudex  file) 

which  is  subordinate  to  the  found  key  on  level  2 for  the 

level-3  key. 

(5)  Add  the  message  identifier  reference  in  the  message 
set  related  to  the  found  level-3  key. 

(6)  Add  the  new  category  reference  to  the  message  descriptor 
record  in  the  Message  Library  file. 

In  the  above  processing  steps,  calls  to  TIMS  perform  steps 
(2),  (3),  and  (4).  The  refile  program,  in  conjunction  with  TIMS 
directives,  must  perform  all  other  processing  steps. 

To  delete  a category  reference  from  a message,  the  steps 
are  the  same  as  above  with  the  exception  that  in  steps  (5) 
and  (6)  the  message  reference  Is  deleted  rather  than  added. 
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To  move  a category  reference  from  one  three-level  Index  to 
another,  the  processing  steps  performed  are  those  for  category 
deletion,  followed  by  the  category  addition  steps  beginning  with 
step  (2). 

d.  Reviewing  Library  Contents 

In  order  that  the  contents  of  the  Message  Library  and  the 
Key  Word  Hierarchical  Index  can  be  monitored,  it  Is  necessary 
to  provide  the  ability  to  review  the  contents  of  each  of  these 
subsets. 

To  review  the  contents  of  the  Key  Word  Hierarchical  Index, 
the  following  processing  steps  are  required: 

(1)  From  the  batch  input  stream,  accept  the  starting  Index 
file  category  to  be  reviewed  and  the  ending  Index  file 
category  to  be  reviewed. 

(2)  Search  the  index  file  for  the  specified  starting  level-1 
category. 

(3)  Search  the  subset  of  level  2 (of  the  index  file)  which 
is  subordinate  to  the  found  level-1  key  for  the  starting 
level- 2 key. 

(4)  Search  the  subset  of  level  3 (Of  the  index  file)  which 
is  subordinate  to  the  found  icvel-2  key  for  the  starting 
level- 3 key. 

(5)  Retrieve  the  message  set  associated  with  the  level-3 
key  and  publish  all  message  identifiers  there. 

(6)  If  the  three-level  index  processed  was  the  ending 
category  to  be  reviewed,  then  terminate. 

(7)  Traverse  the  tree  to  the  next  level-3  entry  and 
obtain  its  subscript.  If  none  exists,  then  proceed  to 
step  (8).  Otherwise  return  to  step  (5). 

(8)  Traverse  the  tree  to  the  next  level- 2 entry  and 
obtain  its  subscript.  If  no  entry  exists,  then  proceed 
to  step  (10). 

(9)  Traverse  the  tree  to  the  first  level-  3 entry  subordinate 
to  the  current  level-2  entry  and  retrieve  its  subscript. 
Return  to  step  (5). 
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(10)  Traverse  the  tree  to  the  next  level-1  entry  and 
retrieve  its  subscript.  Traverse  the  tree  to  the  first 
level-2  entry  subordinate  to  this  level-1  entry  and 
retrieve  its  subscript.  Return  to  step  (9). 

To  review  the  contents  of  the  Message  Library,  the  following 
processing  steps  are  required: 


(1)  From  the  batch  input  stream,  accept  the  starting 
message  identifier  and  the  ending  message  identifier  of 
the  subset  of  the  Message  Library  file  to  be  reviewed. 

(2)  Retrieve  and  publish  the  text  of  the  next  message  along 
with  its  identifier. 

(3)  Repeat  step  (2)  until  all  requested  messages  have  been 
published. 

D.  FUNCTIONAL  SPECIFICATIONS  FOR  THE  SCENARIO  GENERATOR 

It  was  noted  in  Section  B of  this  chapter  that  various  portions 
of  scenario  generation  are  to  be  automated  to  provide  the  speed  and 
flexibility  necessary  in  constructing  scenarios.  Specifically,  these 
steps  are  the  assembling  of  scenario  messages  for  the  exercise,  and  the 
building  of  the  scenario  data  base  and  the  Message  Time  List  for  input 
to  the  AIPERS  Scenario  Processor.  Thus,  the  AIPERS  Scenario  Generator 
is  composed  of  two  primary  components:  the  Scenario  Message  Review  and 

Selection  Component  and  the  Scenario  Formatting  Component.  The  functions 
which  each  of  these  components  perform  are  enumerated  in  the  following 
subsections.  The  final  subsection  describes  the  interfaces  between 
the  Scenario  Generator  components  and  the  remainder  of  the  AIPERS  modules. 

1.  The  Scenario  Message  Review  and  Selection  Component 


The  purpose  of  the  Scenario  Message  Selection  Component 
(SMSC)  is  to  provide  access  to  the  Message  Library  and  text 
editing  facilities  in  order  to  compile  the  scenario  message 
traffic  for  an  AIPERS  exercise.  The  following  processing 
steps  are  required  in  order  to  build  the  scenario  message 
traffic  for  the  exercise: 

(1)  Log  on  to  the  Scenario  Generator  SMSC. 

(2)  Determine  whether  a new  scenario  is  to  be  started, 
or  the  one  under  development  is  to  be  continued. 

(3)  If  a new  scenario  is  to  be  built,  create  a new  scenario 
message  file  and  scenario  index  file.  If  a scenario  pre- 
viously under  development  is  to  be  continued,  open  the 
scenario  message  file  and  scenario  index  file. 
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(A)  Using  a menu  for  user  option  selection,  determine 
whether  the  Message  Library  is  to  be  accessed,  a new 
message  is  to  be  created,  hard  copy  printout  of  the 
scenario  is  to  be  produced,  or  the  procedure  is  to  be 
terminated.  Proceed  to  step  (5),  (15),  (17),  or  (18), 
respectively. 

(5)  If  the  Message  Library  is  to  be  accessed,  display 
the  level-1  categories  of  the  Key  Word  Hierarchical 
Index  for  menu  selection. 

(6)  Once  a level-1  key  is  selected,  display  the 
appropriate  array  of  level-2  keys  for  menu  selection. 

(7)  Once  a level-2  key  is  selected,  display  the  appro- 
priate array  of  level-3  keys  for  menu  selection. 

(8)  Retrieve  the  message  set  referenced  by  the  three- 
level  key  from  the  library  index  file.  This  message 
set  contains  the  message  Identifiers  under  which  the 
actual  messages  are  stored  in  the  Message  Library  file. 

(9)  Retrieve  the  next  message  referenced  from  the 
Message  Library  file.  If  none  remains,  return  to  step  (A). 

(10)  Display  the  message  handling  options  in  the  form  of 

a menu  selection:  review  the  message,  store  the  message 

into  the  scenario,  text  edit  the  message,  delete  the 
message  from  consideration,  and  terminate  processing  of 
this  set  of  messages  from  the  library.  Depending  upon 
the  option  selected,  proceed  to  steps  (11),  (12),  (13), 
(1A),  or  (A),  respectively. 

(11)  If  message  review  i?  selected,  display  the  message  on 
the  terminal  screen.  Upon  indication  of  completion  of  the 
review  by  the  scenario  writer,  return  to  step  (10). 

(12)  If  the  message  is  to  be  added  to  the  scenario,  create 
the  next  scenario  message  ID,  store  the  message  in  the 
scenario  data  base,  and  add  the  message  ID  to  the  scenario 
index.  Delete  the  message  reference  from  the  message  set 
and  proceed  to  step  (9)  above. 

(13)  If  text  editing  of  the  message  is  selected.  Invoke 
the  message  text  editor.  This  editor  will  allow  the 
insertion,  deletion,  and  replacement  of  text  in  the 
message.  Upon  termination  of  text  editing,  return  to 
step  (10)  above. 
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(14)  If  the  message  is  to  be  deleted  from  consideration, 
remove  its  entry  from  the  current  message  set  and  return 
to  step  (9)  above. 

(15)  If  a new  message  Is  to  be  created,  invoke  the 
message  text  editing  facilities  for  new  message  input. 

(16)  Once  message  entry  is  complete,  offer  the  option  of 
either  ignoring  the  message  or  adding  it  to  the  scenario 
under  development.  If  the  message  is  to  be  ignored,  return 
to  step  (4)  above.  Otherwise,  create  the  next  scenario 
message  ID  and  add  the  message  to  the  scenario  data  base. 
Also  add  the  message  to  the  Message  Library,  storing  a key 
word  index  entry  to  it  under  category  "IV-E-1"  (No  Category 
Assigned)  in  the  library  index  file.  Upon  completion  of 
this  process,  return  to  step  (4)  above. 

(17)  If  hard  copy  of  the  scenario  messages  is  requested, 
then  process  each  scenario  message  in  the  scenario  index 
in  sequence.  Retrieve  each  message  from  the  scenario 
file,  format  it  for  output,  and  queue  it  to  the  line 
printer  for  publication.  The  message  format  should  leave 
space  for  the  manual  insertion  of  a time  tag  and  an 
anticipated  analyst's  response  array  (i.e.,  the  hard 
copy  will  be  used  as  a production  worksheet  prior  to 

the  initiation  of  the  Scenario  Formatting  Component). 

(18)  If  the  scenario  writer  chooses  to  terminate  adding 
messages  to  the  scenario  data  base,  then  the  Message 
Library  and  scenario  files  are  closed,  and  the  program 
exits. 

It  should  be  noted  that  much  of  the  processing  required  to 
perform  the  above  steps  will  be  greatly  simplified  by  the  use 
of  TIMS  and  an  appropriate  TOSS  (Terminal  Oriented  Support 
System)  terminal  handler  such  as  TTDL  (Terminal  Transparent 
Display  Language)  macro  calls. 

2.  The  Scenario  Formatting  Component 

Once  all  messages  have  been  selected  for  use  in  the  exercise 
scenario,  it  is  the  purpose  of  the  Scenario  Formatting  Component 
of  the  Scenario  Generator  to  format  the  scenario  data  base  and 
the  Message  Time  List  file  for  use  by  the  AIPERS  Scenario 
Processor.  This  procedure  is  interruptable^  and  will  be  re- 
startable  at  any  point  in  the  process. 


The  Scenario  Formatting  Component  provides  the  scenario 
writer  with  the  ability  to  review  messages  before  final  in- 
clusion in  the  Scenario,  to  delete  previously  Included  messages 
from  the  scenario,  and  to  assign  time  tags  to  scenario  messages, 
as  well  as  anticipated  arrays  of  analyst's  response  when 
needed.  The  processing  steps  required  to  perform  these  func- 
tions are  as  follows: 

(1)  Log  the  scenario  writer  on  to  the  Scenario  Generator 
Scenario  Formatting  Component. 

(2)  Open  the  scenario  data  base  and  scenario  index  file. 

Open  the  Message  Time  List  file.  If  no  MTL  file  exists, 
then  create  a new  MTL  file. 

(3)  Read  through  the  scenario  index  file  until  the  first 
message  entry  not  marked  "deleted"  is  found.  If  all  the 
entries  have  been  processed,  then  proceed  to  step  (11). 

(4)  Retrieve  the  message  referenced  by  the  next  scenario 
index  record. 

(5)  Present  a selection  menu  of  processing  functions  to 
the  scenario  writer  for  selection.  These  options  are 

to  review  the  message;  to  delete  the  message  from  the 
scenario;  and  to  assign  a time  tag  and,  possibly,  an 
analyst's  anticipated  response  array  to  the  message. 

Proceed  to  processing  steps  (6),  (7),  or  (8),  respectively, 
depending  upon  the  function  selected. 

(6)  If  message  review  is  selected,  format  the  message  for 
display  at  the  terminal.  Once  the  scenario  writer  in- 
dicates that  he  is  through  reviewing  the  message,  return 
to  processing  step  (5). 

(7)  Mark  the  scenario  index  record  for  the  message  "deleted" 
(or  "already  processed"),  update  the  scenario  index  pointer 
to  the  next  entry,  and  return  to  step  (4).  If  no  more 
entries  exist  in  the  scenario  index,  then  proceed  to 
processing  step  (11). 

(8)  If  a message  is  to  be  included  in  the  scenario,  request 
a time  tag  in  hours , minutes , and  seconds  from  the  beginning 
of  the  exercise  for  delivery  of  the  message  to  the  I&W 
Center  host  computer.  Using  this  time  tag,  format  an 

MTL  entry  for  this  message.  (Such  an  entry  consists  of 
the  time  tag,  the  unique  message  identifier,  and  space 
for  message  status.)  Store  the  MTL  entry  into  the 
appropriate  slot  in  the  MTL  file.  (The  MTL  file  is  kept 
sorted  in  ascending  order  by  time  tag.) 
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(9)  Request  the  analyst's  anticipated  response  array 
and  values.  (See  Chapter  IV  of  this  document  for 
more  details  regarding  the  format  of  such  an  array.) 

If  none  is  supplied,  then  return  to  step  (7).  Other- 
wise, store  the  response  array  with  its  associated 
message  in  the  scenario  data  base. 

(10)  Return  to  step  (7)  to  finish  processing  of  the 
message . 

(11)  Upon  request  for  termination  of  the  function,  deter- 
mine if  all  messages  in  the  scenario  index  have  been 
processed.  If  not  then  simply  close  the  scenario  index 
in  anticipation  of  resuming  the  procedure  at  another 
time;  otherwise  delete  the  scenario  index  file.  Close 
the  scenario  data  base  and  Message  Time  List  files, 

and  then  exit. 

Note  that,  as  with  the  Message  Review  and  Selection  Component, 
much  of  the  processing  required  to  perform  the  above  functions 
will  be  greatly  simplified  by  the  use  of  TIMS  directives  as 
well  as  the  TOSS  terminal  handler  (TTDL)  directives. 

3.  Scenario  Generator  Interfaces 

Interfaces  exist  between  the  internal  components  of  th° 
Scenario  Generator,  as  well  as  between  the  Scenario  Generator 
and  other  AIPERS  components.  These  interfaces  all  consist  of 
data  files,  and  are  briefly  described  below. 

a.  Internal  Interfaces 

The  interfaces  between  the  Scenario  Message  Review  and 
Selection  Component  and  the  Scenario  Formatting  Component 
consist  of  the  scenario  data  base  which  contains  all 
messages  selected  for  entry  into  the  scenario,  as  well 
as  the  scenario  index  file.  The  scenario  index  file 
contains  an  entry  for  each  scenario  message  including  its 
unique  identifier  and  its  current  status. 

b.  External  Interfaces 

All  interfaces  between  the  Scenario  Generator  and 
other  AIPERS  components  are  static:  they  consist  of 

data  files  constructed  by  one  component  for  use  by 
another. 


ma.  *-T^e  Me®sage  Library  Maintenance  module  creates  and 
maintains  the  scenario  message  library  for  use  by  the 
Scenario  Generator.  The  Scenario  Generator  does  store 
new  messages  into  this  library,  but  leaves  the  task 
of  categorizing  (indexing)  new  messages  for  the  library 
maintenance  routines.  y 

.nH  JP1®  Sce"ario  Generator  builds  the  scenario  data  base 
and  Message  Time  List  file  for  input  to  the  AIPERS 
Scenario  Processor.  Before  the  exercise  is  run  (i.e. 
before  the  Scenario  Processor  is  initiated),  all  scenario 

twoSfil  datS  ^ time  ta8  dSta  mU3t  be  stored  ^ these 
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CHAPTER  III 

FUNCTIONAL  DESIGN  SPECIFICATIONS  FOR 
THE  AIPERS  SCENARIO  PROCESSOR 


A.  INTRODUCTION 

The  Scenario  Processor  of  the  Automated  Intelligence  Processes 
Exercise  and  Review  System  (AIPERS)  is  the  focal  place  of  exercise 
activities  within  the  AIPERS.  The  functional  design  specifications  for 
the  AIPERS  Scenario  Processor  include  all  the  functions  identified  as 
required  for  retrieving  messages  from  the  Scenario  data  base  and  delivering 
them  to  the  designated  I&W  center's  host  computer.  They  also  include  the 
functions  required  by  the  Control  Team  to  maintain  control  over  the 
flow  of  the  exercise  in  near-real-time.  The  remainder  of  this  chapter 
discusses  the  primary  functions  performed  by  the  Scenario  Processor, 
the  auxiliary  functions  supported  by  the  Scenario  Processor,  the  functional 
interface  between  the  Scenario  Processor  and  the  I&W  center's  host,  and 
the  functional  interfaces  between  the  Scenario  Processor  and  the  other 
AIPERS  components. 

B.  PRIMARY  SCENARIO  PROCESSOR  FUNCTIONS 

The  Scenario  Processor  performs  two  primary  functions  for  the 
AIPERS:  it  maintains  the  exercise  system  clock,  and  it  forwards  scenario 

message  traffic  to  the  I&W  host  computer  at  the  specified  time  intervals. 
Each  of  these  functions  is  discussed  further  in  the  following  subsections. 

1.  Exercise  Clock  Maintenance 

The  entire  AIPERS  is  based  upon  timed  sequences  of  events 
including  delivering  exercise  scenario  message  traffic  to  the 
I&W  host  at  specified  time  intervals  and  measuring  the  analyst's 
responses  to  the  scenario  events  during  specified  timed  Intervals. 
Thus,  there  is  a requirement  for  a centralized  AIPERS  exercise 
clock.  The  Scenario  Processor  is  responsible  for  maintaining 
this  clock. 

The  exercise  clock  measures  time  from  the  start  of  the 
exercise.  It  is  currently  envisioned  that  this  clock  will  be 
maintained  in  seconds  from  the  start  of  the  exercise,  although 
further  development  of  the  AIPERS  may  indicate  that  an  exercise 
clock  kept  in  minutes  from  the  start  of  the  exercise  will  provide 
sufficient  accuracy. 

2.  AIPERS  Scenario  Message  Traffic  Processing 

The  Scenario  Processor  is  the  AIPERS  component  which 
retrieves  exercise  messages  from  the  prestored  scenario  and 
forwards  the  messages,  as  indicated  by  an  attached  time  tag, 
to  the  I&W  host. 
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The  pre-stored  scenario  data  base  will  be  generated  off-line 
using  the  facilities  of  the  AIPERS  Scenario  Generator  (see 
Chapter  II  of  this  document).  The  Scenario  will  consist  of 
messages  stored  as  records  in  the  data  base  and  response 
arrays  stored  as  associated  records  for  each  message.  As 
the  scenario  messages  and  their  associated  response  arrays 
are  stored  in  the  scenario  data  base  by  the  AIPERS  Scenario 
Generator,  a corresponding  entry  will  be  made  in  the  Message 
Time  List  (MTL)  file.  The  MTL  is  a master  directory  of  the 
exercise  scenario  and  will  be  used  by  the  Scenario  Processor 
for  managing  the  retrieval  and  delivery  of  scenario  messages, 
as  well  as  housekeeping  functions  for  restart  and  recovery 
purposes.  Each  entry  in  the  MTL  will  contain  a unique  message 
identifier;  a time  tag;  and  any  other  pertinent  information 
required  by  the  Scenario  Processor  for  retrieving  a message, 
its  response  array,  or  for  retaining  historical  data  for 
restart  and  recovery.  The  MTL  entries  will  be  sorted  in 
ascending  order  based  upon  time  tags.  The  MTL  will  be  blocked, 
as  required,  for  use  by  the  Scenario  Processor.  During  the 
initialization  process  for  the  AIPERS,  the  Scenario  Processor 
will  read  the  first  MTL  block  from  disk,  obtain  the  exercise 
elapsed  time  (the  MTL  time  tag)  for  the  first  exercise  message, 
request  an  entry  in  the  Real  Time  clock  queue,  and  relinquish 
control  of  the  processor. 

Upon  expiration  of  the  Real  Time  clock  queue  entry,  the 
Scenario  Processor  will  regain  control  of  the  processor 
(wakeups),  retrieve  the  message  from  the  scenario  data  base, 
and  forward  the  message  to  the  I&W  host.  Following  this, 
the  Scenario  Processor  will  update  the  MTL  entry  for  the 
message,  indicating  that  it  has  been  forwarded,  and  it  will 
write  the  updated  MTL  block  to  disk.  Any  time  the  MTL  block 
is  updated,  it  will  be  written  to  disk  for  restart  and  recovery 
purposes. 

As  each  message  is  forwarded  to  the  I&W  host,  the  Scenario 
Processor  will  notify  the  Exercise  Tracker  component  so  that 
the  tracking  data  base  can  be  appropriately  updated.  Upon 
finishing  the  processing  of  each  MTL  entry  the  next  entry  is 
obtained  from  the  MTL  and  placed  in  the  Real  Time  clock  queue 
for  processing. 

C.  AUXILIARY  SCENARIO  PROCESSOR  FUNCTIONS 

In  addition  to  its  primary  functions  of  timing  and  forwarding 
scenario  message  traffic  to  the  I&W  center  host,  the  Scenario  Processor 
also  provides  support  functions  used  by  the  AIPERS  Control  component. 

These  support  functions  include  exercise  start,  stop,  and  restart; 
scenario  message  retrieval  for  Control  Team  review;  and  scenario  alteration 
by  the  Control  Team.  The  various  auxiliary  Scenario  Processor  functions 
are  enumerated  and  described  in  the  following  subsections.  Note  that 
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the  AIPERS  Exercise  Tracker  component  Is  notified  by  the  Scenario  Processor 
as  each  of  the  following  functions  is  performed: 

1.  Exercise  Start,  Stop,  and  Restart 

Tart  of  the  Control  Team  function  conducted  by  the  AIPERS 
Control  component  is  to  initiate  the  exercise  system  and 
determine  whether  to  start  the  exercise  from  the  beginning 
or  to  restart  it  where  it  was  terminated  by  command  or  system 
malfunction.  In  addition,  the  Control  Team  can  stop  the  exercise 
at  any  time. 

Upon  notification  of  exercise  start-up,  the  Scenario 
Processor  conducts  its  normal  Initialization  function.  This 
initialization  procedure  is  discussed  at  length  in  Section  B-2. 
of  this  Chapter. 

Upon  notification  by  the  Control  component  of  exercise 
restart,  the  Scenario  Processor  scans  through  the  MTL  until 
the  last  message  is  found  which  has  been  previously  processed. 

The  exercise  clock  is  then  set  to  the  time  tag  of  this  message, 

and  processing  of  the  scenario  is  resumed  by  placing  the  next 

MTL  entry  onto  the  Real  Time  clock  queue. 

If  the  Control  Team  deems  it  necessary  to  stop  the  exercise, 

the  Control  component  notifies  the  Scenario  Processor  of  this 

fact.  The  Scenario  Processor  in  turn  notifies  the  Exercise 
Tracking  Component,  closes  all  data  files,  and  exits  the 
system. 

2.  Exercise  Pause  and  Resume 

The  Control  component  of  AIPERS  provides  the  exercise 
Control  Team  with  the  ability  to  temporarily  suspend  the 
processing  of  the  scenario,  as  well  as  the  ability  to  resume 
the  exercise  after  it  has  been  suspended. 

When  the  AIPERS  Control  component  notifies  the  Scenario 
Processor  that  a pause  in  the  exercise  has  been  requested, 
the  Scenario  Processor  stops  the  exercise  clock  and  suspends 
its  operation  until  further  notice.  This  function  allows 
the  I&W  center  to  process  any  backlog  in  scenario  traffic 
which  may  have  accumulated.  Once  the  backlog  is  processed, 
the  Control  Team,  via  the  AIPERS  Control  component,  can 
instruct  the  Scenario  Processor  to  resume  its  operation. 

At  this  time,  the  Scenario  Processor  restarts  the  exercise 
clock  and  continues  to  process  scenario  messages  as  before. 

3.  Scenario  Review 

The  Scenario  Processor  is  also  responsible  for  supporting 
the  Control  component  of  AIPERS  in  requests  by  the  Control  Team 
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to  review  the  scenario.  The  Control  component  passes  requests 
for  scenario  message  and/or  response  array  review  to  the 
Scenario  Processor.  The  Scenario  Processor  then  searches 
the  MTL  for  the  requested  message,  retrieves  the  message 
and/or  response  array  from  the  scenario  data  base,  and 
forwards  the  data  to  the  Control  component  for  display  at 
the  Control  Team  console. 

4.  Scenario  Alteration 

The  Scenario  Processor  is  responsible  for  processing  all 
Control  Team  requests  to  alter  the  scenario.  These  requests, 
which  are  forwarded  to  the  Scenario  Processor  by  the  AIPERS 
Control  component.  Include  message  modification,  addition, 
delay,  deletion,  and  reentry.  Each  of  these  functions  is 
described  in  the  following  subsections. 

a.  Message  Modification 

If,  after  reviewing  a scenario  message,  the  Control 
Team  deems  it  necessary  to  modify  the  message  text,  the 
Control  component  supports  text  editing  functions  for 
message  editing.  Once  the  message  is  modified  to  the 
satisfaction  of  the  Control  Team,  the  Control  component 
passes  the  new  text  to  the  Scenario  Processor.  The  Scenario 
Processor  deletes  the  old  message  text  and  replaces  it  with 
the  new  text. 

b.  Message  Addition 

The  Scenario  Processor  interfaces  with  the  AIPERS 
Control  component  to  allow  the  acceptance  of  ad  hoc 
messages  into  the  scenario  data  base  from  the  Control 
Team.  These  ad  hoc  messages  will  be  sent  from  the  Control 
Team  console  to  the  Scenario  Processor.  The  Scenario 
Processor  will  append  the  message  to  the  scenario  data 
base  and  insert  an  entry  in  sequence  in  the  MTL  based 
on  the  time  tag  of  the  ad  hoc  message.  The  updated  MTL 
block  is  then  written  to  disk.  There  will  be  no  response 
arrays  associated  with  ad  hoc  messages. 

c.  Message  Delay 

The  Scenario  Processor  accepts  requests  for  message 
delay  from  the  Control  Team  via  the  AIPERS  Control 
component.  Once  a request  for  message  delay  is  received, 
the  Scenario  Processor  deletes  the  original  MTL  entry 
for  the  message,  and  inserts  the  new  entry  for  the 
message  into  the  MTL.  The  updated  MTL  block(s)  is 
then  written  to  disk. 
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d.  Message  Deletion 


When  the  Control  Team  requests  that  a message  be 
deleted  from  the  scenario,  the  AIPERS  Control  component 
forwards  this  request  to  the  Scenario  Processor  for 
processing.  The  Scenario  Processor  marks  the  message 
status  in  its  MTL  entry  "deleted"  and  writes  the  updated 
MTL  block  to  disk. 

e.  Message  Reentry 

The  Scenario  Processor  accommodates  requests  for 
scenario  message  reentry.  These  requests  are  originated 
by  the  Control  Team,  and  are  passed  to  the  Scenario 
Processor  by  the  AIPERS  Control  component.  Upon  receiving 
such  a request,  the  Scenario  Processor  looks  up  the 
message's  MTL  entry  and  marks  it  "not  deleted."  If  the 
time  tag  for  delivery  of  the  message  to  be  reentered  has 
also  been  changed,  then  the  Scenario  Processor  deletes 
the  old  MTL  entry  for  the  Message  and  Inserts  a new  entry 
for  the  message  into  the  proper  sequence  in  the  MTL.  In 
either  case,  all  affected  MTL  blocks  are  written  to  disk 
for  restart  and  recovery  purposes. 

D.  SCENARIO  PROCESSOR  FUNCTIONAL  INTERFACES 

The  Scenario  Processor  Interfaces  with  the  I&W  center's  host 
computer  as  well  as  with  the  various  other  AIPERS  components.  Each 
of  these  interfaces  is  described  in  the  following  subsections. 

1.  External  Interfaces 

The  Scenario  Processor  interfaces  with  the  I&W  center's 
host  computer  for  the  purpose  of  transmitting  exercise  scenario 
message  traffic  to  the  analysts  participating  in  the  exercise. 

It  is  currently  assumed  that  the  I&W  host  will  route  the 
scenario  messages  to  the  appropriate  participating  analyst's 
station(s) . 

2.  Internal  Interfaces 

Internal  to  the  AIPERS,  the  Scenario  Processor  has  both 
passive  and  active  interfaces  with  various  AIPERS  components. 

A passive  interface  exists  betweeu  the  AIPERS  Scenario  Generator 
and  the  Scenario  Processor  in  that  the  Scenario  Generator  builds 
the  scenario  data  base  and  the  Message  Time  List  prior  to 
initialization  of  the  exercise.  The  Scenario  Processor  takes 
over  control  of  these  two  data  files  upon  start  up  of  the 
exercise. 

During  the  course  of  the  exercise,  the  Scenario  Processor 
maintains  active  Interfaces  with  the  AIPERS  Control  component 
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and  the  AIPERS  Tracking  component.  The  Scenario  Processor 
accepts  inputs  from  the  AIPERS  Control  component  for  the 
purpose  of  near-real-time  exercise  flow  control  and  for 
scenario  modification.  The  AIPERS  Tracking  component  is 
notified  by  the  Scenario  Processor  every  time  the 
Scenario  Processor  completes  a discrete  function.  These 
functions  Include  the  transmission  of  each  message  to  the 
I&W  center's  host  computer  and  the  processing  of  Control 
Team  requests. 


CHAPTER  IV 


TECHNICAL  ASPECTS  OF  METHODOLOGIES  FOR  APPLYING  DECISION 
IMPACT  ANALYSIS  TO  AUTOMATED  EXERCISE  CONTROLS 


A.  INTRODUCTION 

During  the  execution  of  an  exercise,  a major  concern  with  respect 
to  player  participation  is  the  matter  of  how  he  may  respond  to  discrete  or 
collective  scenario  stimulations.  How  he  may  respond  is  germane  because  an 
aberrant  response  may  well  precipitate  undesirable  exercise  trends.  Exercise 
activity  levels  may  become  unacceptably  high  or  low,  future  event  stimulators 
of  the  scenario  may  be  preempted,  or  the  accomplishment  of  exercise  objectives 
may  be  precluded.  For  these,  and  perhaps  myriad  other  reasons,  the  predict- 
able consequences  of  such  responses  would  be  desirable  as  Control  Team  informa- 
tion. As  was  earlier  noted  (in  RADC-TR-75-252) , the  goal  of  decision  Impact 
analysis,  "...at  any  point  in  time  is  to  provide  an  assessment  of  the  poten- 
tial, possible,  probable  or  known,  impact  that  an  analyst's  choice  of  optional 
activities  may  have  upon  the  exercise  at  the  time  of  choice  or  at  a later 
time." 

The  analysis  of  the  impact  which  player  decisions  can  have  may 
be  made  initially  at  the  time  of  scenario  generation.  At  the  moment  of  event 
selection,  an  array  of  possible  responses — in  the  context  of  the  total  scen- 
ario exposed  to  that  time — should  be  developed.  Without  such  an  array,  the 
timely  consideration  of  analyst  actions  would  be  difficult  at  best.  It  is 
essential  to  note  that  arrays  for  each  exercise  scenario  will  vary  signifi- 
cantly. They  will,  in  fact,  vary  for  the  same  event  in  separate  exercises 
because  the  context,  world  political  scene,  and  exercise  parameters  will 
differ. 

Excursions  into  the  attempted  definition  and  articulation  of  Deci- 
sion Impact  Analysis  have  indicated  that  to  know  what  it  is  not  is  most  prob- 
j ably  as  significant  as  to  know  what  it  is.  In  this  chapter,  therefore, 

both  Issues  will  be  addressed.  Any  success  that  may  be  achieved  in  the  con- 
version ol  analyst's  responses  to  scenario  stimulations  into  quantitative 
values  for  error  signal  generation  will  be  predicated  upon  the  clear,  unam- 
biguous definition  of  the  functional  expanse  of  Decision  Impact  Analysis. 

B.  TIME  STRUCTURED  FILES 

Assessments  of  the  impact  of  decisions  made  by  exercise  participants 
at  any  time  are  highly  dependent  upon  the  availability  of  time  structured 
files  of  information.  Each  scenario  event  must  be  given  a finite  time  window 
during  which  it  must  be  processed  and  those  time  windows  must  be  constantly 
available  to  the  Control  Team.  With  such  an  aid,  the  Control  Team  will  be 
able  to  look  ahead  at  scenario  events  to  determine  whether  a player  decision 
at  tj  will  have  any  impact  upon  the  planned  activities  at  t . This,  how- 
ever, is  in  a manual  mode  of  analysis. 
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The  automation  of  response  assessment  is  predicated  upon  comparisons 
of  player  actions  with  those  which  were  designed  into  the  scenario  with 
anticipated  response  arrays.  In  the  following  example,  the  generation  of 
decision  impact  analysis  error  signals  will  be  traced. 

SCENARIO  ELEMENT 
AES- 000011 

FM:  DATT,  TAIWAN 

TO:  INCO,  INC.  INTEL.  SIM.  CTR. 

RE:  BROUHAHA  IN  OFF-SHORE  WATERS  OF  TAIWAN 

REF:  OPER.  INTEL.  REPORT  REQ. 

DTG:  11  1800  OCT  00 

THE  FOLLOWING  MESSAGE  FROM  THE  REUTER'S  NEWS  AGENCY  IS 
TRANSMITTED  VERBATIM  FOR  YOUR  INFORMATION.  TAIPEI, 

TAIWAN  11  OCTOBER.  THE  MINISTER  OF  FOREIGN  AFFAIRS 
FOR  NATIONALIST  CHINA  SPEAKING  BEFORE  A GROUP  OF  DIP- 
LOMATIC PERSONNEL  IN  TAIPEI  ON  THE  ANNIVERSARY  OF  THE 
REPUBLIC,  ALLUDED  ON  SEVERAL  OCCASIONS  TO  THE  HIS- 
TORIC ATTACHMENT  OF  VARIOUS  ISLAND  GROUPS  TO  CHINA. 

SPECIFIC  REFERENCE  WAS  MADE  TO  THOSE  BETWEEN  THE  BASHI 
AND  BALINTANG  CHANNELS.  THE  REASON  FOR  THIS  CONTEN- 
TION IS  UNCLEAR,  AND  THE  INTERNATIONAL  RESPONSE  IS 
EXPECTED  TO  BE  VIGOROUS. 

Given  that  the  message  was  received  in  a sufficiently  meaningful 
context  of  on-going  events,  it  could  be  anticipated  that  the  analyst  or  exer- 
cise player  would  respond  in  a manner  within  predictable  limits.  If  this  were 
also  the  initial  message  on  the  subject,  and  if  the  objectives  of  the  exercise 
included  reviewing  analyst's  procedures,  the  array  of  responses  would  probably 
resemble  the  following: 

ACTIONS 


DTG  VALUE 

TAKEN 

RESPONSE 

11  1800  a. 

+4 

5 

Flag  item  for  briefing,  and 

b. 

+3 

4 

Request  additional  info  from  DATT,  and 

c. 

+2 

3 

Request  ANALIT  from  PACOM,  and 

d. 

±o 

2 

Refer  to  B.E. /Gazetteer  for  exact  location 
and  then  refer  to  map 

e. 

-1 

1 

Refer  to  map  for  location 

f. 

-1.5 

0 

Does  nothing 

The  spread  of  values  in  this  instance  is  small;  positive  values 
represent  varying  degrees  of  over-response  and  negative  values  represent 
under-response.  Considering  that,  at  this  time,  the  message  appears  quite 
routine,  to  do  nothing  about  it  is  judged  to  be  less  Inappropriate  than  to 
stir  up  collection  resources.  It  does  seem  appropriate,  however,  that  the 
analyst  should  ascertain  the  geographical  locations  of  the  referenced  and 
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obscurely  named  channels.  Subsequent  events  In  their  proximity  might  cause 
the  contents  of  this  message  to  have  greater  meaning.  Assume  the  passage  of 
routine  l&W  and  current  Intelligence  traffic  for  the  following  three  hours 
and  then  the  receipt  of  the  next  message. 

AES-000021 

FM:  DIRNSA 

TO:  INCO,  INC.  INTEL.  SIM.  CTR. 

RE:  PHILIPPINE  NAVAL  UNITS  SEIZE  JAPANESE  FISHING  VESSELS 

REF:  OPER.  INTEL.  REPORT  REQ. 

DTG:  11  2100  OCT  00 

COAST  GUARD  UNITS  OF  THE  PHILIPPINE  NAVY  ARE  REPORTED 
TO  HAVE  SEIZED  A NUMBER  OF  JAPANESE  FISHING  VESSELS  IN 
THE  VICINITY  OF  THE  BATAN  ISLANDS.  JAPANESE  CREWS  HAVE 
BEEN  PLACED  IN  CUSTODY  OF  THE  COAST  GUARD  DETENTION 
FACILITY  OFFICIALS  AT  APARRI.  DISPOSITION  OF  THE  VES- 
SELS IS  UNKNOWN.  THIS  IS  THE  FIRST  KNOWN  INSTANCE  OF 
PHILIPPINE  SENSITIVITY  ABOUT  THE  OFF-SHORE  WATERS  OF  THE 
ISLAND  GROUP.  NO  STATEMENT  HAS  BEEN  MADE  BY  PHILIPPINE 
OFFICIALS  REGARDING  THE  INCIDENT  SO  FAR. 


ACTIONS 


DTG 

VALUE 

TAKEN 

RESPONSE  - INITIAL 

11  2100 

a. 

+6 

6 

Requests  traffic  analysis  by  DIRNSA 
(prior  5 days),  and 

b. 

+4 

5 

Activates  collection  effort/notifies 
C&C  element,  and 

c. 

+2 

3 

Alerts  team  chief  of  incipient  crisis,  and 

d. 

±0 

2 

Refers  to  B.E. /Gazetteer  for  locations  of 
Batan  Islands  and  Aparri  and  then  to  map 

e . 

-1 

1 

Queries  OB  files  for  information  regarding 
P.I.  coast  guard  equipment 

f . 

-3 

0 

Does  nothing 

RESPONSE  - SECOND 

a. 

+8 

5 

Requests  DIRNSA  traffic  analysis,  requests 
PACOM  ANALIT,  and 

b. 

+4 

3 

Notifies  C&C  element  of  crisis,  and 

Ce 

+2 

2 

On  basis  of  11  2100  Oct  msg.  alone,  gener- 
ates briefing  item,  and 

d. 

±0 

1 

Recalls  msg.  of  11  1800  Oct  for  review  and 
correlation  of  information  with  that  of 
11  2100  Oct 

e . 

-2 

1 

Consults  with  area  analyst  for  history 
of  such  events 

f. 

-4 

0 

Does  nothing 
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The  second  message  introduces  two  additional  place  names  into  the 
scenario,  names  which  probably  will  not  be  readily  familiar  to  the  exercise 
player  unless  he  happened  to  be  a specialist  on  the  Philippine  Islands.  It 
would  seem  likely  that  he  would  again  ascertain  the  locations  where  the 
reported  events  occurred  as  a first  response.  As  in  the  first  instance,  the 
event  in  Isolation  lacks  any  great  significance;  but  when  viewed  in  light  of 
the  former  message,  it  may  arouse  curiosity  or  concern.  It  is  assumed  that 
the  analyst  would  seek  to  review  the  earlier  message  and  correlate  the  two 
as  being  related. 

The  values  assigned  to  the  spectrum  of  responses  are  subjective 
and,  perhaps,  somewhat  arbitrary;  but  experience  gained  from  the  frequent 
experimentation  with  response  arrays  should  provide  more  accurate  techniques 
of  relative  weighting. 

To  carry  the  methodology  further,  and  then  to  illustrate  error 
signal  generation  by  Control  Team  use  of  tracker  Information,  consider  these 
subsequent  messages: 

AES-000023 

FM:  FBIS 

TO:  INCO,  INC.  INTEL.  SIM.  CTR. 

RE:  RADIO  PEKING  CRITICIZES  PHILIPPINE  SEIZURES 

REF:  DIRNSA  MSG  11  2100  OCT  00 
DT3:  120130  OCT  00 

THE  FOREIGN  BROADCAST  INFORMATION  SERVICE  REPORTS 
THAT  A CHI  COM  SPOKESMAN  OVER  RADIO  PEKING  CRITI- 
CIZED THE  PHILIPPINE  USE  OF  NAVAL  FORCE  IN  INTER- 
NATIONAL WATERS.  THE  CRITIC  REFERRED  TO  THE  INCI- 
DENT AS  HAVING  OCCURRED  IN  PRC  COASTAL  WATERS. 

THE  CONTEXT  IN  WHICH  THE  CRITICISM  WAS  MADE  IS 
OBSCURE.  THERE  HAVE  BEEN  NO  KNOWN  PHILIPPINE 
INTRUSIONS  INTO  PRC  TERRITORIAL  WATERS. 


AES-000027 


FM: 

DEPARTMENT  OF  STATE 

TO: 

INCO,  INC.  INTEL.  SIM.  CTR. 

RE: 

REQUEST  FOR  ASYLUM,  MARIA  TOLMOY 

TORSA 

REF: 

DOD  REQ.  FOR  INFO 

DTG: 

12  0300  OCT  00 

MARIA 

TOLMOY  TORSA,  DAUGHTER  OF  GEORGE 

TOLMOY 

CHAIRMAN  OF  THE  EAST  PACT  CENTRAL  COMMITTEE,  HAS 
REQUESTED  ASYLUM  IN  THE  UNITED  STATES.  SHE  HAS 
BEEN  IN  RESIDENCE  IN  MANDO  FOR  THE  PAST  TWENTY- 
TWO  MONTHS.  HER  STATUS  WITHIN  MANDO  HAS  BEEN 
EQUIVALENT  TO  THAT  OF  A GUEST  OF  THE  STATE,  WITH 
AN  UNLIMITED  VISA  BUT  NO  DIPLOMATIC  OR  OFFICIAL 
ACCREDITATION.  MRS.  TORSA  WAS  BORN  ON  29  JUNE  1924 
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IN  PARTOVA,  LAST  PACT,  AND  SHE  HAS  ONF  SON, 
VLADIMIR,  WHO  RESIDES  IN  LAST  PACT.  AT  THE 
PRESENT  TIME  SHI  IS  SEPARATED  FROM  HER  SECOND 
III  SHAM)  WHO  IS  A NATIVE  OF  MANDO.  SHE  REQUESTS 
ASYLUM  ONLY  FOR  HERSELF  AND  (.IVES  HER  REASONS 
FOR  THIS  REQUEST  AS  DESIRE  TO  FIND  SAFETY,  SEC- 
URITY, AND  PEACE  OF  MIND  IN  THE  WEST.  HER  CLOSE 
ASSOCIATION  WITH  HER  FATHER  OVER  THE  LAST  TWO 
DF.CADF.S  SHOULD  PROVIDE  AN  INTIMATE  AND  SOUND 
BASE  FOR  A SCHOLARLY  REVIEW  OF  TOE  SOCIO-POLITICAL 
SITUATION  IN  EAST  PACT  FOR  THE  PAST  20  YEARS. 

AES-000032 

FM:  DEPT.  OF  STATE 

TO:  INCO,  INC.  INTEL.  SIM.  CTR. 

RE:  CHINA  PROTESTS  USE  OF  U.S.  AID  BY  PHILIPPINES 

REF:  DIRNSA  11  2100  OCT  00 

L'TG : 12  1930  OCT  00 


NATIONALIST  CHINA  HAS  LODGED  A PROTEST  WITH  THE  U.S. 
STATE  DEPARTMENT  REGARDING  THE  USE  OF  MILITARY  AID 
EQUIPMENT  BY  THE  PHILIPPINE  GOVERNMENT  DURING  THE 
SEIZURE  OF  .JAPANESE  FISHING  VESSELS  IN  THE  BASHI 
FLANNEL . THE  BASIS  FOR  TOE  CHI  NAT  INTRUSION  INTO 
THE  AFFAIR  IS  TOE  CLAIM  THAT  THE  BATAN  ISLANDS  ARE 
HISTORICALLY  CHINESE. 

AES-000035 

FM:  FB1S 

TO:  INCO,  INC.  INTEL.  SIM.  CTR. 

RE:  TAIWAN  THREATENS  L.S.  USE  OF  CCK  AIRBASE 

REF:  DIPT.  OF  STATE  MSG  12  1930  OCT  00 

DTG : 12  2200  OCT  00 

A FOREIGN  BROADCAST  INFORMATION  SERVICE  REPORT 
INDICATES  THAT  TAIPEI  LEADERS  ARE  SERIOUSLY  CON- 
SIDERING THE  ABROGATION  OF  THE  AGREEMENTS  WITH  THE 
U.S.  OVER  THE  USE  OF  CCK  AIR  BASE  BY  THE  U.S.  AIR 
FORCE.  CCK  IS  OF  MAJOR  IMPORTANCE  TO  THE  CONTINUED 
PRESENCE  OF  U.S.  AIR  POWER  IN  TOE  WESTPAC  AREA. 

: HE  REASON  FOP  CONSIDERING  CLOSURE  OF  THE  BASE  IS 
SOMEWHAT  OBSCURE  IN  THAT  ITS  USE  IS  INCORPORATED  IN 
THE  REPUBLIC  OF  CHINA  — U.S.  MUTUAL  DEFENSE  PACT. 

AES-000036 

FM:  DATT,  PHILIPPINES 

TO:  INCO,  INC.  INTEL.  SIM.  CTR. 

E:  PHILIPPINES  MAY  RESTRICT  USE  OF  U.S.  BASES  THERE 

FF.F : DIRNSA  MSG  121930  OCT  00 

DTG:  13  0200  OCT  00 


DISCUSSIONS  WERE  ENTERED  INTO  THIS  DATE  WITH  COL. 
ROMULO,  AN  AIDE  TO  THE  PHILIPPINE  DEFENSE  CHIEF. 
THE  AIDE  IMPLIED  THAT  PRESIDENT  MARCOS  WILL 
OPENLY  SOLICIT  REASSURANCE  OF  U.S.  SUPPORT  WITH 
REGARD  TO  THE  BATAN  ISLANDS  SOVEREIGNTY  CONTRO- 
VERSY WITH  NATIONALIST  CHINA.  IT  WAS  INDICATED 
THAT  MARCOS  WOULD  CONSIDER  ANYTHING  OTHER  THAN  A 
POSITIVE  RESPONSE  TO  BE  AMPLE  REASON  TO  WARRANT 
A SERIOUS  REVIEW  OF  THE  STATUS  OF  BOTH  CLARK  AIR 
BASE  AND  THE  NAVAL  FACILITIES  OF  SUBIC  BAY.  AS 
A MINIMUM  PHILIPPINE  REACTION,  THE  PROHIBITION 
OF  U.S.  AIRCRAFT  USING  CLARK  A.B.  IN  CONJUNCTION 
WITH  FLIGHTS  TO  OR  FROM  TAIWAN  WOULD  BE  EXPECTED. 


AES-000039 


FM: 

US  NAVAL  INTEL  CTR. 

TO: 

INCO,  INC.  INTEL.  SIM. 

CTR. 

RE: 

CHINA/PHILIPPINE  NAVAL 

MOVEMENTS 

REF: 

OPER.  INTEL.  DEPT.  REQ. 

DTG: 

13  0600  OCT  00 

CHINESE  NATIONALIST  NAVAL  DESTROYER  NO.  T-017 
REPORTED  TO  BE  LOCATED  25  NM  DUE  SOUTH  OF  SOUTH- 
ERN TIP  OF  TAIWAN  MOVING  ON  A TRUE  BEARING  OF 
125  DEGREES  AT  2016  ZULU  13  OCTOBER.  REPUBLIC 
OF  PHILIPPINES  TORPEDO  BOATS  (2)  P-123, P-267 
SIGHTED  30  MILES  N-NW  OF  LINGAYEN  ON  COURSE 
TOWARD  BALINTANG  CHANNEL.  2003  ZULU  13  OCTOBER. 

AES-000041 

FM:  AIRLO,  HONG  KONG 

TO:  INCO,  INC.  INTEL.  SIM.  CTR. 

RE:  GARUDA  B-707  POSSIBLY  DOWN 

REF:  OPER.  INTEL.  REPORT  REQ. 

DTG:  13  1000  OCT  00 

FOLLOWING  IS  A VERBATIM  TRANSMISSION  OF  A HONG 
KONG  NEWS  RELEASE  DATED  13  OCTOBER,  HONG  KONG. 
HONG  KONG  NEWS  HAS  REPORTED  THAT  A GARUDA  AIR- 
LINES BOEING  707  IS  BELIEVED  TO  BE  DOWN  AT  SEA 
SOUTH  OF  TAIWAN.  THE  AIRCRAFT,  FLIGHT  B216  WAS 
BOUND  FOR  JAKARTA  FROM  TOKYO  AND  WAS  LAST  HEARD 
FROM  AT  A LOCATION  100  MILES  N.E.  OF  HU ALIEN, 
TAIWAN.  THE  FLIGHT  CARRIED  123  PASSENGERS  PLUS 
CREW  AND  DEPARTED  TOKYO  INTERNATIONAL  AIRPORT 
AT  1710  ZULU  ON  13  OCTOBER.  OFFICIALS  OF  A 
NATIONALIST  CHINESE  TRADE  COMMISSION  WERE 
REPORTED  TO  HAVE  BEEN  ABOARD. 
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AES-000044 


FM:  DIRNSA 

TO:  INCO,  INC.  INTEL.  SIM.  CTR. 

RE:  PHILIPPINE  ARTILLERY  COMMO.  REG.  AIR  SCHEDULES 

REF:  ROUTING  COMMO.  REPORTING 

DTG:  13  1200  OCT  00 

USN  VOICE  INTERCEPT  OF  CONVERSATION  BETWEEN 
PHILIPPINE  ARMY  COASTAL  ARTILLERY  POST  AT  AN 
UNDISCLOSED  LOCATION  AND  A HEADQUARTERS  ELEMENT 
IN  THE  MANILA  AREA  REVEALED  THAT  SPECIAL  INTER- 
EST HAD  BEEN  GENERATED  WITH  REGARD  TO  INTER- 
NATIONAL AIR  ROUTES  TRAVERSING  WATERS  ADJACENT 
TO  LUZON.  REFERENCES  TO  FLIGHT  NUMBERS  AND  ETAS 
TO  REPORTING  POINTS  WERE  MADE.  THE  INTEREST  OF 
A COASTAL  ARTILLERY  UNIT  IN  SUCH  MATTERS  IS 
UNUSUAL  AND  ITS  PURPOSE  OBSCURE.  PORTIONS  OF 
THE  CONVERSATION  REVERTED  TO  TAGALOG  AND  HAVE 
NOT  BEEN  TRANSLATED. 

AES-000047 

FM:  DEPT.  OF  TRANSPORTATION 

TO:  INCO,  INC.  INTEL.  SIM.  CTR. 

RE:  ICAO  REQUESTS  U.S.  RESCUE  SEARCH  ASSIST 

REF:  AIRLO  HONG  KONG  MSG  13  1000  OCT  00 

DTG:  13  1300  OCT  00 

INTERNATIONAL  CIVIL  AVIATION  ORGANIZATION  (ICAO) 

OFFICIALS  HAVE  REQUESTED  THE  UNITED  STATES  TO 
PARTICIPATE  IN  SEARCH  OPERATIONS  BEING  ORGANIZED 
TO  FIND  A MISSING  GARUDA  AIR  707.  THE  AIRCRAFT 
IS  BELIEVED  TO  HAVE  DISAPPEARED  DUR1NC  EARLY 
MORNINC  HOURS  OF  13  OCTOBER  IN  THE  VICINITY  OF 
BATAN  ISLANDS  NORTH  OF  LUZON.  U.S.  AIRCRAFT  MAY 
USE  CLARK  AB  ON  LUZON  OR  CCK  ON  TAIWAN  IF  AGREE- 
MENT IS  REACHED  WITH  THE  RESPECTIVE  GOVERNMENTS. 

Based  upon  the  foregoing  sequence  of  messages  which  progressively 
ties  together  what  were,  upon  first  analysis,  unrelated  events,  discrete 
response  arrays  may  be  structured  prior  to  the  exercise.  Subsequently,  the 
response  values  for  "actions  taken"  as  opposed  to  predicted  responses  will  be 
assembled  into  an  activity  profile.  The  following  response  arrays  are 
related  to  message  DTGs. 
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ACTIONS 


DTG 

VALUE 

TAKEN 

RESPONSE 

12  0130 

a. 

+4 

5 

Flags  events  for  Indications  watch,  and 

b. 

+3 

4 

Requests  ANALIT  from  PACOM,  and 

c. 

+2 

3 

Requests  State  Department  analysis  of  ter- 
ritorial questions  seemingly  involved,  and 

d. 

±° 

2 

Designates  the  accumulating  events  as  an 
area  of  continued  interest.  Constructs 
working  file  to  track  events. 

e. 

-3 

1 

Fails  to  develop  working  file 

f . 

-4 

0 

Takes  no  action 

12  0300 

a. 

+2 

2 

Requests  biographic  data  on  Maria  Torsa,  and 

b. 

±° 

1 

Checks  out  locations  and  relationships  of 
MANDO  and  EAST  PACT 

c . 

-2 

0 

Disregards  message 

12  1930 

a. 

+4 

3 

Requests  PACOM  ANALIT,  and 

b. 

+2 

2 

Requests  amplifying  information  from 
STATE,  and 

c. 

+0 

1 

Adds  message  info  to  working  files 

d. 

-2 

0 

Does  nothing 

12  2200 

a. 

+4 

4 

Requests  further  info  from  STATE,  and 

b. 

+2 

3 

Tasks  NSA  for  relevant  information,  and 

c. 

+0 

2 

Relays  information  to  C&C  duty  officer  and 
flags  events  to  date 

d. 

-2 

1 

Relays  information  to  C&C  element  only 

e. 

-5 

0 

Does  not  contact  C&C  element 

13  0200 

a. 

+4 

4 

Tasks  DATT  for  additional  info,  and 

b. 

+2 

3 

Seeks  additional  info  from  STATE,  and 

c. 

±0 

2 

Adds  message  info  to  working  files;  passes 
info  to  C&C  element 

d. 

-3 

1 

Fails  to  notify  C&C  element 

e. 

-5 

0 

Fails  to  add  message  to  working  files  or 
pass  info  to  C&C  element 

13  0600 

a. 

+5 

6 

Queries  CINCPAC  for  additional  info,  and 

b. 

+3 

5 

Requests  amplifying  info  from  NOSIC,  and 

c. 

±° 

4 

Plots  locations  of  reported  events,  passes 
info  to  C&C  element,  adds  message  info 
to  working  files.  Requests  info  on  any 
U.S.  naval  vessels  in  area. 

d. 

e. 

-3 

-6 

2 

Only  plots  location  of  reported  events  and 
passes  info  to  C&C  element 
Fails  to  notify  C&C  element  but  takes  other 
+0  actions 
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DTG 


ACTIONS 
VALUE  TAKEN 


RESPONSE 


13  10(90  a.  +0  5 Alerts  and  requests  available  info  from 

DATT/Manila  and  Taipei.  Flags  event  as 
possibly  related  to  previous  messages 
relating  to  CHINAT/PHILIPPINE  contro- 
versy. Requests  related  info  from  NSA. 
Requests  ANALIT  from  CINCPAC. 

b.  -3  3 Fails  to  query  NSA  and  to  associate  event 

with  previously  reported  controversy 

c.  -5  2 Fails  to  query  NSA,  to  correlate  event  and 

to  request  ANALIT 

d.  -10  0 Fails  to  seek  any  additional  information 

or  to  take  any  relevant  action 

13  1200  a.  +3  6 Requests  STATE  to  make  inquiries  in  Manila, 

and 

b.  +2  5 Requests  13AF  I&W  center  for  additional 

information,  and 

c.  +0  4 Flags  event  of  downed  airlines  as  "hot 

news."  Correlates  intercept  info  with 
possible  shoot  down.  Begins  to  assemble 
a briefing  item.  Advises  C&C  element. 

d.  -5  1 Correlates  intercept  info  with  possible 

shoot  down 

e.  -8  0 Fails  to  take  any  of  above  actions 

13  1300  a.  +0  2 Passes  info  to  C&C  element.  Uses  data  in 

briefing  item  which  supposes  shoot  down 
of  a Garuda  airliner. 

b.  -2  1 Fails  to  take  one  of  above  actions 

c.  -4  0 Fails  to  take  both  actions  above 

The  response  arrays  which  have  been  presented  are  so  structured 
that  a constant  activity  level  of  +0  represents  that  proper  actions  are  being 
taken.  If  it  is  postulated  that  the  actual  analyst'  activities  were  as  next 
indicated,  an  activity  profile  may  be  constructed.  (see  Figure  IV-1) 


NO.  OF  NO.  OF 

ACTIONS  ACTIONS 


DTG 

RESPONSE 

VALUE 

TAKEN 

DTG 

RESPONSE 

VALUE 

TAKEN 

11-1800 

c. 

+2 

2 

12-2200 

c. 

+0 

2 

11-2100 

b. 

2 

13-0200 

b. 

+2 

2 

11-2100 

c. 

+2 

1 

13-0600 

b. 

+3 

4 

12-0130 

d. 

+0 

2 

13-1000 

a . 

+0 

5 

12-0300 

a. 

+2 

1 

13-1200 

a. 

+3 

4 

12-1930 

a . 

+4 

1 

13-1300 

a. 

+0 

2 
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RESPONSE  VALUES 


f* 


I 

PROJECTED 
SUM  OF 


DATE/TIfC  GROUP  OF  MESSAGE 


Figure  IV- 1.  Exercise  Activity  Profile  Using  Weighted  Response  Arrays 


Assuming  for  the  moment  that  the  arrays  of  response  are  valid,  the 
actual  exercise  profile  indicates  that  the  exercise  participants  are  "over- 
reacting" to  the  scenario  as  it  is  processed.  If  the  Control  Team  is  to  main- 
tain exercise  activity  levels  at  or  near  those  desired,  dampening  inputs 
should  be  made,  in  this  instance,  no  later  than  the  13-1200  time  so  that  the 
exercise  profile  will  parallel  the  "desired  sum  of  actions."  In  this  proce- 
dure for  following  the  exercise,  the  actual  profile  would  not,  in  all  likeli- 
hood, return  to  the  "desired  sum  of  actions"  level;  only  by  taking  deficit 
actions  or  underreactions  for  a prolonged  period  would  it  so  return.  Regard- 
less of  overreaction  in  the  past,  the  desired  level  of  exercise  activity 
represented  by  a horizontal  line  would  be  sought. 
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NUN6ER  OF  ACTIONS 


r 


A second  method  of  computing  relative  exercise  activity  levels 
would  be  represented  thusly  (Figure  IV-  2): 


DATE/TI&C  GROUP  OF  MESSAGE 


Figure  IV-2.  Exercise  Activity  Profile  Using  Relevant  Actions  Taken 


RELEVANT  ACTIONS  TAKEN 


11-1800 

3 

12-2200 

2 

-19 

11-2100 

5 

-8 

13-0200 

3 

-22 

11-2100 

2 

-10 

13-0600 

5 

-27 

12-0130 

2 

-12 

13-1000 

5 

-32 

12-0300 

2 

-14 

13-1200 

6 

-38 

12-1930 

3 

-17 

f 


In  this  example,  the  decisions  made  by  the  analyst  are  converted 
into  discrete  actions  taken.  The  sum  (cumulative)  of  "programmed  actions" 
versus  the  actual  actions  taken  are  graphically  compared.  Similar  projections 
may  be  made  in  this  instance  and  corrective  actions  taken  to  cause  the  two 
progressions  to  parallel  one  another. 

A significant  problem  arises  in  this  second  approach.  Referring  to 
the  response  array  for  13-0600,  it  is  apparent  that  the  most  significant 
action  to  be  taken  is  informing  the  C&C  element  of  the  event.  Should  response 
"e"  be  made,  a serious  deficiency  in  appropriate  actions  taken  would  occur  as 
indicated  by  the  -6  value  assigned  in  the  first  approach;  but  according  to  the 
count  of  actions  taken,  the  weight  would  be  (3)  which  is  greater  than  for 
response  "d"  which  includes  the  report  of  the  event  to  the  Command  Post.  Such 
ambiguities  as  this  one  would  have  to  be  eliminated  before  this  assessment 
approach  could  be  validated. 

Another  facet  of  the  overall  problem  of  developing  values  for  the 
determination  of  the  impact  (or  import)  of  the  analyst's  decision  making  pro- 
cess upon  the  exercise  is  that  of  whether  overreaction  to  an  event  should  be 
"handicapped"  to  the  same  extent  as  underreaction.  The  objective  in  this  as 
in  most  training  environments  is  to  induce  efficiency  in  actions  responsive 
to  real  world  or  scenario  events.  Implicit,  then,  is  the  goal  of  not  over- 
driving the  system,  i.e.,  the  data  bases,  communications  lines,  collection 
management,  etc.  Instances  occur  which  reflect  excessive  and  unwarranted 
activities  and  which  show  a lack  of  discrimination  as  to  what  is  and  what  is 
not  important  or  deserving  of  thorough  treatment.  Refinements  to  the  I&W 
system  are  in  part  directed  toward  ensuring  that  time  and  resources  are 
always  available  for  the  really  important  events.  It  is  important  in  the 
exercise  environment  that  the  proper  training  occurs  which  will  achieve  such 
efficiencies.  An  additional  aspect  of  efficiency  in  action,  however,  is  that 
of  responding  adequately  to  real  world  or  exercise  events.  Ensuring  adequate 
response  would  seem  to  occupy  a priority  position  with  respect  to  overreac- 
tions to  event  stimulation.  Therefore,  a review  of  the  typical  response 
arrays  previously  noted  suggests  that  (+)  values  should  be  scaled  down  and  the 
(-)  value  responses  accentuated  both  in  number  and  value.  With  such  an 
adjustment,  deficiencies  in  activity  levels  will  become  readily  discernible 
and  Control  Team  ad  hoc  injects  will  be  stimulative  rather  than  predominantly 
dampening. 


For  additional  insight  into  the  quantification  of  decision  impact 
analysis,  reference  is  made  to  the  previous  report,  RADC  TR-75-252,  Section  V. 

C.  THE  COMPONENT  ELEMENTS  OF  DECISION  IMPACT  ANALYSIS 

Inputs  to  the  equation  for  the  evolvement  of  decision  analysis 
which  may  be  identified  from  the  preceding  message  traffic  and  response 
arrays  are  several  and  of  varied  types.  Each  analytical  assessment  performed 
by  the  exercise  participant,  his  decisions  and  products  developed  (e.g., 


I 


IV- 12 


brlollng  notes,  memoranda,  working  file  entries)  along  with  Control  Team 
In |eets  are  among  the  dynamic  Inputs.  Assessments  may  be  largely  predicated 
upon  I lie 


o Scenario  context  in  which  the  event  occurs 

o Time  structuring  of  the  scenario 

o Availability  of  collatteral  information 

o Analyst's  particular  familiarity  with  or 
expertise  regarding  the  event 

The  Control  Team  may  be  expected  to  respond  to  or  interpret  the  results  of 
the  analytical  assessment  made  with  respect  to  its  timeliness,  relevance,  and 
adequacy  in  developing  a response  value.  As  was  previously  noted  in 
RADC  TR-75-252,  Section  V,  response  handling  will  initially  require  Control 
Team  intervention  in  relaying  that  value  to  the  AIPERS  Decision  Analysis 
Module  (ADAM) . Such  a requirement  for  human  intervention  will  be  necessary 
because : 

o The  analyst's  response  must  be  matched  against 
a predicted  response  array  for  each  major  event. 
Response  patterns  and  procedures  are  not  yet 
standardized  sufficiently  to  permit  matching 
by  key  words  or  phrases.  The  matching  must  be 
done  by  a Control  Team  member. 

o A response  value  is  assigned  to  each  predicted 
response.  If  the  real  response  is  substantially 
identical  to  one  of  those  predicted,  the  value 
can  be  read  and  relayed  to  the  ADAM  for  plotting. 
However,  if  the  response  is  slightly  different, 
or  significantly  different,  the  value  will  be 
decreased  or  Increased  - a Control  Team  member 
must  assign  it  a value  and  relay  the  value  to 
the  ADAM. 

o I'npredicted  responses  cannot  be  matched  as 
indicated  above.  Therefore,  the  required 
answers  to  these  responses  (request  for 
collection,  material,  information,  etc.)  must 
be  authored  by  the  Control  Team  and  fed  to 
the  Scenario  Processor  for  entry  into  the 
exercise  at  an  appropriate  time. 

D.  SUMMARY 

From  the  work  conducted  this  far  regarding  the  definition, 
deliniation  and  integration  of  decision  impact  analysis  into  exercise  control 
procedures,  the  performance  characteristic  parameters  may  be  established  with 
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a reasonable  degree  of  certainty.  Decision  analysis  is  a deliberate, 
contextually  derived,  attention  demanding  tool  for  use  by  an  exercise  Control 
Team  in  ensuring  that  the  objectives  of  a particular  exercise  are  met. 

Success  in  the  effective  employment  of  that  tool  is  predicated  upon  the 
exhaustive  identification  of  the  total  spectrum  of  possible  analyst’s  or 
watch  officer's  responses.  That  spectrum  is  finite,  being  restricted  by  the 
resources  available  to  the  functional  area  undergoing  exercise. 


Figure  IV-3  illustrates  the  flow  of  Information  within  the 
exercise  system  relevant  to  the  use  of  Decision  Impact  Analysis  in  the  control 
function.  The  exercise  tracker  performs  a key  role  in  assisting  the  Control 
Team  to  employ  decision  analysis  because  it  closes  the  loop  with  the  analyst. 
The  two  components  of  the  exercise  message — the  text  with  header  information 
and  the  anticipated  array  of  responses — are,  in  effect,  split  apart  or  un- 
coupled as  the  message  enters  the  exercise  arena.  The  text  passes  through 
the  scenario  processor  while  its  related  response  array  is  passed  to  the 
ADAM.  The  latter  module  compares  the  weighted  array  with  the  specific 
response,  and  is  then  passed  to  ADAM  by  the  tracker.  The  comparison  effected 

is  made  available  to  the  Control  Team  as  is  the  Tracker  output.  Using  the 
provided  information,  the  Control  Team  maintains  an  exercise  activity  profile 
using  one  or  both  of  the  methodologies  previously  discussed.  Using  the 
profile  as  guidance,  intervention  into  the  exercise  may  be  elected  or  the 
more  subtle,  essentially  invisible,  option  of  injecting  an  ad  hoc  message 
or  messages  into  the  scenario  stream  may  be  taken.  The  effects  of  Control 
Team  participation  may  then  be  metered  by  the  iterative  process  described 
above  and  adjustments  to  that  participation  may  be  made. 


- 
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SECTION  A 


INTRODUCTION 


1.  PURPOSE  AND  REFERENCES 

a.  Background  and  Purpose 

Under  the  direction  of  the  Rome  Air  Development  Center, 
the  technical  staff  of  INCO,  INC.,  of  McLean,  Virginia  ha9  combined  the 
transfer  of  advanced  Terminal  Oriented  Support  System  (TOSS)  technology 
with  a selectively  targeted  R&D  effort  to  produce  an  innovative  automated 
system  for  exercise,  evaluation  and  training.  The  system's  evaluation 
capabilities  will  enable  an  indications  and  warning  (I&W)  or  other 
functional  manager  to  institute  comprehensive  check-out  procedures  to 
evaluate  the  adequacy  and  thoroughness  of  intelligence  support  facilities 
of  analysts  or  watch-officers  during  simulated  crisis  conditions.  A 
second  major  performance  characteristic  of  the  exercise  system  is  its 
utility  as  a training  medium  both  for  the  enhancement  of  analytical 
skills  and  for  the  development  of  personal  proficiencies  in  operating 
the  automated  aids.  The  degree  of  automation  presently  occurring  at 
major  I&W  centers  has  warranted  the  adoption  of  such  a minimal  cost 
exercise  system  to  ensure  that  the  expensive  hardware  and  software  support 
systems  are  performing  efficiently. 

The  exercise  system  has  been  entitled  the  Automated  Intel- 
ligence Processes  Exercise  and  Review  System  or  AIPERS.  Design  of 
system  has  progressed  in  such  a way  as  to  make  it  fully  adaptable  to 
other  evaluation  and  training  environments  such  as  CPXs,  command  and 
control,  and  reconnaissance  - intelligence  interfaces. 

The  primary  objectives  of  the  effort  to  date  have  been  to 
complete  the  R&D  efforts  attendant  to  automated  scenario  processing 
and  to  Initiate  those  relevant  to  automated  scenario  generation,  and 
to  develop  a Demonstration  Utility  Prototype  (DUP)  of  AIPERS  which  will 
integrate  the  tracking  and  control  functions  previously  developed  with 
scenario  processing.  The  latter  objective  will  be  used  in  conjunction 
with  post-exercise  evaluative  methodologies  and  tools  of  measurement. 

The  purpose  of  this  User's  Manual  is  to  provide 
functional  analysts  the  information  required  to  use  the  AIPERS 
Demonstration  Utility  Prototype  (DUP)  effectively.  The  manual  in- 
cludes a brief  description  of  functions  now  available  in  the  DUP 
repertoire,  and  the  actions  the  analyst  must  perform  to  interact  with 
the  system  to  use  them.  Step-by-step  procedures  and  sample  CRT  dis- 
plays are  shown  to  guide  the  analyst  through  the  process  of  entering 
data  the  system  needs  to  perform  the  functions  he  selects. 
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b. 


References 


DUP  program  descriptions  and  Installations  procedures 
are  contained  in  the  following  document: 

o AIPERS  Interim  Program  Description, 

11  March,  1976 

Terminal  Transparent  Display  Language  (TTDL)  Terminal 
operation  and  control  features  are  contained  in  the  following  document: 

o TTDL  Programmer's/User's  Manual, 

15  August,  1975  (Revision  to  be  available 

16  April,  1976) 

Certain  error  codes  which  may  appear  are  explained  in 
the  following  documents: 

o TIMS  Programmer 's  Manual 

July,  1975  Revision  2 

o ISC  Programmer's  Manual 

30  June,  1975  Phase  1,  Revision  6 
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SECTION  B 


CONTROL  TEAM  TERMINAL  FUNCTIONS 


CKN’ERAL 

.1.  introduction 

The  Exercise  Control  Team  is  provided  various  controls  for 
the  exercise  on  an  as  needed  basis.  These  controls  include 
stopping  the  exercise,  restarting  the  exercise,  reviewing  the 
current  scenario  message,  retrieving  and  reviewing  any  scenario 
message  by  message  ID,  adding  ad  hoc  messages  to  the  scenario, 
deleting  messages  from  the  scenario,  and  reordering  scenario 
messages  by  modifying  time  tags. 

b . Log  On 

The  Log  On  procedure  for  the  Exercise  Control  Team  (ECT)  is 
strictly  a mechanical  initialization  function.  Establishment  of 
identitv  and  security  authorization  are  not  required.  Log  On 
procedures  are  as  follows: 

o Position  cursor  at  command  line 

o Type  in  RUN^ECPtf [ 2 char  screen  name].  Hit  CTRL  A. 

c.  Exercise  Initialization  (Comes  Up  Automatically) 

This  will  initialize  the  exercise  so  that  other  modules  may 
be  loaded.  A screen  is  presented  requesting  exercise  parameters, 
to  wit: 

o Include  the  number  of  analyst  stations 

o Indicate  whether  new  exercise  or  restart  recovery 
from  a previous  exercise. 

This  display  is  illustrated  in  Figure  V-l. 

The  ENTER  DATA  key  is  depressed  (throughout  this  document 
the  term  "ENTER  DATA  key"  is  used  as  a convention.  Different 
terminal  manufacturers  use  varying  terminology,  e.g.,  SEND 
PACE,  TRANSFER,  etc.  The  corresponding  Tektronix  4010  key 

is  ALTMODE). 
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Fissure  V-l.  Exercise  Configuration  Display 


At  this  point,  the  exercise  begins  and  the  ECT  assumes  its 
function  of  controlling  the  exercise.  The  menu  of  control  team 
functions  is  presented,  as  illustrated  in  Figure  V-2. 

To  select  any  function,  only  the  number  to  the  left  of  the 
function  must  be  entered.  From  this  point  on,  exercise  control 
consists  of  choosing  a function,  performing  the  function,  and 
being  returned  to  the  function  menu. 

2.  CONTROL  FUNCTIONS 

a.  Function  1:  Stop  the  Exercise 

At  any  point  in  time,  the  demonstration  may  be  stopped  by 
entering  "1",  and  the  equivalent  for  the  given  terminal  of  ENTER 
DATA.  Files  are  closed  and  the  programs  are  terminated  and  un- 
loaded. It  should  be  noted  that  the  depression  of  the  ENTER  DATA 
when  no  function  has  been  selected  will  have  the  same  effect. 
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CONTROL  TEAM  FUNCTIONS  MENU 

1.  STOP  THE  EXERCISE 

2.  REVIEW  THE  CURRENT  SCENARIO  MESSAGE 

3.  RFVIEW  THE  MESSAGE  LOG 

A.  REVIEW  ANY  SCENARIO  MESSAGE 

5.  ADD  A NEW  MESSAGE  TO  THE  SCENARIO 

6.  DF.LFTE  A MESSAGE  FROM  THE  SCENARIO 

7.  MODIFY  A SCENARIO  MESSAGE 

8.  CHANGE  A SCENARIO  MESSAGE  TIME  TAG 

INPUT  DATA:  5 


Figure  V-2.  Exercise  Control  Team  Functions  Menu  Display 


b.  Function  2:  Review  the  Current  Scenario  Message 

This  is  the  message  which  the  Scenario  Processor  is  currently 
displaying  at  the  analyst  stations.  Selection  of  "2"  enables  the 
EOT  to  identify  and  review  this  message.  If  no  message  is 
currently  being  displayed,  the  ECT  is  so  informed.  Otherwise,  the 
message,  including  header  and  text,  is  formatted  for  display;  the 
time  tag  and  current  status  bits  of  the  message  are  also  displayed. 

In  the  example  shown  in  Figure  V-3,  there  is  no  current 
message.  Figure  V-4  illustrates  the  display  of  the  current 
scenario  message. 


r 


Figure  V-3.  No  Current  Scenario  Message  Display 
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AES-020400 


ANAYWHERE 

INCO,  INC.  INTEL.  SIM.  CTR 
ANY  S"BJECT 

WHICH  REFERENCES  IF  ANY 
03  2043  MAR  76 


THIS  IS  A SAMPLE  MESSAGE.  IT  INCLUDES  ONLY  ONE  TEXT 
SECTION. 


TIME  TAG 
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Figure  V-4.  Current  Scenario  Message  Display 


c.  Function  3:  Review  the  Message  Log 

The  Message  Log  is  a file  of  74  character  records  generated 
by  the  Scenario  Processor.  Each  record  consists  of  the  Message  ID 
and  the  "RE"  header  line  from  the  message.  When  reviewing  the 
Message  Log,  the  function  builds  a list  of  each  message  that  has 

been  sent  to  the  analyst  station  plus  the  "RE"  line.  In  the 
example  shown  in  Figure  V-5,  there  are  no  messages  in  the 
log.  Figure  V-6  illustrates  the  display  created  after  six 
messages  have  been  processed  by  the  Scenario  Processor. 

d.  Function  4:  Review  any  Scenario  Message 

This  function  requires  the  entry  of  the  six  character  message 
ID  parameter  as  well  as  the  function  number  ("4") . This  ID 
identifies  the  specific  message  to  be  reviewed.  The  entire  message 
including  header,  text,  time  tag,  and  status  is  displayed.  This 
is  identical  to  Function  2,  except  that  a specific  message  is 
identified.  A sample  message  for  review  is  illustrated  in 
Figure  V-7. 
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AES-010000 


FM: 

ANYWHERE 

TO: 

INCO,  INC.  INTEL 

RE: 

ANY  SUBJECT 

REF: 

WHICH  REFERENCES 

DTG: 

03  2130  MAR  76 

SIM.  CTR. 


THIS  IS  THE  TEXT  OF  THE  MESSAGE.  THIS  IS  THE  NEW  LINE.  ALL 
EXTRANEOUS  INPUT  FIELD  CHARACTERS  WILL  BE  REMOVED  FROM  THE 
TEXT  BY  THE  EDITOR. 

THIS  IS  THE  SECOND  TEXT  SECTION.  IT  WAS  ADDED  TO  SHOW  WHAT 
MORE  THAN  ONE  TEXT  SECTION  CAN  BE  A PART  OF  THE  MESSAGE 

TIME  TAG  - 00:01:00 

MESSAGE  STATUS: 
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Hgure  V-7.  Review  Scenario  Message  Display 


e.  Function  5:  Add  a New  Message  to  the  Scenario 

When  this  function  is  selected,  the  first  thing  to  appear  on 
the  screen  is  the  Message  Editor  Functions  menu  (see  Section  D of 
this  chapter).  The  Message  Editor  will  be  waiting  for  input  in 
the  form  of  both  header  and  text.  The  editor  then  builds,  reviews, 
and  edits  the  new  message.  Control  is  passed  back  to  "a  new  message" 
function,  which  determines  if  the  message  is  complete.  If  not,  an 
error  screen  is  displayed.  A "Time  Tag  Entry"  screen  is  then 
displayed.  A time  tag  in  hours/mlnutea/aeconds  from  the  start 
of  the  exercise  is  requested.  This  display  is  illustrated  in 
Fiaure  V-8. 


This  time  tag  is  compared  to  the  current  message  time 
tag.  If  the  new  message  time  tag  has  expired  (i.e.,  is  less 
than  the  current  message  time  tag) , the  ECT  is  requested  to 
reenter  a valid  tag.  Should  the  ECT  not  be  able  to  come  up 
with  a tag  which  the  program  considers  valid  (a  "loop"  situation 
develops),  an  invalid  character  in  the  time  tag  field  will 
cause  return  to  the  Control  Function  menu. 

When  a valid  time  tag  is  accepted,  the  message  ID  is 
assigned,  the  message  is  added  to  the  Message  Library,  and 
the  time  tag  is  added  to  the  Message  Time  List  (MTL)  file. 

Note  that  a time  tag  may  not  be  equal  to  one  already  in  the 

MTL  file. 
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! VTI.K  T1NF  TAO  (HH:MM:SS)  - VALl'E  IN  F. LAPSED  TIME  FROM 
1.XKH  IS!'  START  - <K):Q1:QQ 


Figure  V-o.  Enter  Time  Tag  Display 


i.  Function  6:  Delete  a Message  from  the  Scenario 

This  function  requires  the  entry  of  the  Message  ID  parameter 
as  well  as  the  function  number.  The  function  scans  the  MTL  and, 
if  it  finds  such  an  ID,  marks  it  deleted  without  actually 
removing  the  entry.  A status  bit  is  set  to  indicate  that 
the  message  was  deleted.  If  the  message  ID  is  not  found, 
an  error  message  appears  on  the  screen.  Otherwise,  the 
Control  Team  functions  menu  is  returned  to  the  Screen.  The 
error  display  is  illustrated  in  Figure  V-9. 
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Modi  tv  a Scenario  Message 
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1 1, In  i mu  i Inn  requires  tlie  entry  of  the  II)  ol  the  message  to 
In-  mnilflinl.  The  massage  In  retrieved  II  possible,  from  the  Message 
Resource  Tile.  An  error  screen  Is  returned  if  the  message  cannot 
he  found.  If  found,  the  text  will  be  accessed  and  formatted  pro- 
perly lor  the  Message  Editor  (see  Section  D of  this  chapter). 

Control  is  passed  to  the  Message  Editor,  which  allows  the  ECT  to 
review  and  modify  the  message.  Once  complete,  control  is  passed 

back  to  the  message  modification  function.  This  function 
determines  if  any  text  remains  in  the  message;  if  not,  an 
error  message  is  displayed  and  the  request  is  ignored.  If 
text  does  remain,  the  new  message  is  stored  in  place  of  the 
old  on  the  Message  Resource  File.  The  MTL  entry  for  the 
message  is  located  and  the  status  word  is  updated  to  indicate 
that  the  message  has  been  modified. 

h.  Function  8:  Change  a Scenario  Time  Tag 

To  change  the  designated  time  after  the  start  of  an 
exercise  that  a message  is  to  be  sent,  select  this  option. 

The  message  ID  parameter  must  be  entered.  A screen  illustrated 
in  Figure  V-8,  will  be  displayed  requesting  the  entry  of  the 
new  time  tag  (the  old  time  tag  can  be  found  by  use  of  Function  4: 
Review  Scenario  Message).  The  new  time  tag  is  checked  to  insure 
that  it  has  not  expired,  and  if  not,  the  MTL  file  is  updated.  If 
the  new  tag  has  expired  or  is  equal  to  any  current  time  tag,  the 
user  is  Informed. 
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SECTION  C 
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ANALYST  STATION  FUNCTIONS 


1.  GENERAL 

a.  Introduction 

This  section  describes  the  functions  which  may  be  employed 
by  the  analyst  at  his  exercise  work  station.  The  analyst  work 
station  in  the  DUP  consists  of  a CRT  terminal.  The  CRT  is 
broken  into  two  screens.  The  upper  half  of  the  screen  is 
reserved  for  the  display  of  the  current  scenario  message. 

The  lower  half  of  the  screen  is  devoted  to  typical  analyst 
functions  such  as  current  message  acknowledgement  and  accessing 
of  various  resources  such  as  data  bases.  The  format  of  the 
analyst  work  station  terminal  screen  is  illustrated  in  Figure  V-10. 
Manipulation  of  the  terminal  between  the  two  screen  areas  as  well 
as  paging  displays  is  discussed  in  Section  E. 


J 

h . Access 

Access  to  the  two  portions  of  the  DUP  analyst  work  station 
screen  is  gratuitous;  that  is,  no  log  on  sequence  is  required. 
The  top  screen  area  may  be  accessed  immediately  upon  forwarding 
of  tile  first  scenario  message  by  the  scenario  processor. 

The  lower  portion  of  the  screen  is  accessible  upon  forwarding 
of  the  analyst  functions  selection  menu.  All  access  to  both 
screen  areas  is  terminated  once  the  exercise  termination 
message  is  transmitted  to  the  lower  screen  area.  This  is 
illustrated  in  Figure  V-ll. 
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ANALYST  MESSAGE  REVIEW  FUNCTION 


All  scenario  messages  are  forwarded  to  the  analyst  work 
station  by  predetermined  time  tag.  Each  message  is  formatted  into  a 
display  and  transmitted  to  the  upper  half  of  the  analyst  terminal  screen. 
Each  time  a new  message  is  transmitted,  it  replaces  the  previous  message 
in  the  display  area.  A sample  message  in  the  analyst  station  message 
display  area  is  illustrated  in  Figure  V-12.  Once  the  message  has  been 
written  to  the  top  screen  area,  it  is  available  for  review  by  the 
participating  analyst.  If  the  message  consists  of  multiple  pages,  it 
can  be  paged  forward  and  backward  using  the  terminal  paging  function 
keys  (see  Section  E) . 


Figure  V-l'>  ‘ample  Scenario  Message  Display 
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ANAI.YST  MESSAGE  PROCESSING  FUNCTIONS 


A variety  of  message  processing  functions  are  available  for 
use  by  the  participating  analyst  through  the  lower  half  of  the  work 
station  terminal  screen.  These  functions  include: 

o Acknowledge  the  current  message 

o Generate  a report 

o Review  the  message  log 

o Review  a previous  message 

o Access  queryable  resources 

o Access  non-queryable  (request-oriented)  resources 

o Record  access  of  hard  copy  resources 

Every  exercise  is  configured  during  exercise  generation  to 
provide  access  to  eight  specific  resources.  Each  of  these  resources 
is  accessible  via  one  of  the  latter  three  functions  types  listed  above. 

The  first  display  which  appears  on  the  lower  half  of  the 
analyst  work  station  terminal  screen  is  the  analyst  message  processing 
functions  menu.  Such  a menu  with  eight  typical  resources  is  illustrated 
in  figure  V-13.  Each  time  a function  is  completed  this  menu  is  returned 
to  the  terminal  screen.  Each  use  of  the  specific  function  types  is 
described  in  the  following  subsections. 


figure  V-13.  Analybt  Message  Processing  Functions  Menu  Display 


a.  Acknowledge  the  Current  Message 

This  function  allows  the  analyst  to  acknowledge  that 
he  has  read  the  message  in  the  current  message  display  of 
his  work  station  (the  top  half  of  the  terminal  screen).  To 
acknowledge  the  current  message,  the  analyst  enters  "1" 
in  the  "INPUT  DATA"  area  followed  by  the  equivalent  for  the 
given  terminal  of  ENTER  DATA.  When  this  function  is  selected, 
the  analyst  is  informed  that  the  current  message  has  been 
acknowledged  by  the  display  illustrated  in  Figure  V-14. 

Once  ENTER  DATA  is  struck,  the  Analyst  Functions  Menu  is 
returned  to  the  lower  half  of  the  terminal  screen. 


Figure  V-14.  Current  Message  Acknowledgement  Display 
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b.  Generate  a Report 

This  function  is  selected  by  entering  a "2"  into  the 
Analyst  Functions  Menu  input  field  followed  by  ENTER  DATA. 

It  allows  the  analyst  to  build  a report  in  the  form  of  a 
message  and  transmit  it  to  the  appropriate  authorities. 

When  this  function  is  selected,  the  first  thing  to  appear 
on  the  screen  is  the  Message  Editor  Functions  menu  (see 
Section  D of  this  chapter) . The  Message  Editor  will  accept 
input  in  the  form  of  both  header  and  text;  and  will  allow 
the  message/report  to  be  built,  reviewed,  and  edited  as 
necessary  until  it  is  ready  for  forwarding.  Control  is 
returned  from  the  Message  Editor  to  the  "Generate  a Report" 
function,  which  determines  whether  the  report  contains  any 
text.  If  no  text  is  present,  an  error  message  (illustrated 
in  Figure  V--15)  is  transmitted  to  the  screen  and  the  reporting 
function  is  terminated.  Otherwise,  the  message/report  is 
forwarded,  the  analyst  is  informed  of  this  action  (see 
Figure  V-16),  and  control  is  returned  to  the  functions  menu. 


Figure  V-15.  Incomplete  Report  Error  Display 
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YOUR  REPORT  HAS  BEEN  FORWARDED. 


Figure  V-16.  Completed  Report  Forwarding  Display 


c.  Review  the  Message  Log 

The  Message  Log  is  a file,  generated  by  the  Scenario 
Processor,  which  contains  an  entry  for  each  scenario  message, 
which  has  already  been  transmitted  to  the  analyst  station. 
Each  entry  in  this  Log  consists  of  the  Message  ID  (e.g., 
AES-020471)  followed  by  the  message  header  "RE"  line.  The 
analyst  function  to  review  the  Message  Log  is  selected  by 
entering  "3"  in  the  Analyst  Functions  menu  followed  by  ENTER 
DATA.  Figure  V-17  illustrates  the  display  which  is  returned 
if  no  entries  have  yet  been  made  in  the  Log.  Figure  V-18 
illustrates  a typical  display  generated  from  a log  with 
several  message  entries. 
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Figure  V-17.  Empty  Message  Log  Display 


d. 


Review  a Previous  Message 


This  function  allows  the  analyst  to  recall  a previously 
displayed  scenario  message  for  review  on  the  lower  half  of  his 
terminal  screen.  The  function  is  initiated  by  entering  a "4" 
into  the  input  field  of  the  Analyst  Functions  menu  followed 
by  ENTER  DATA.  Once  initiated,  the  function  requests  the 
message  ID  of  the  message  to  be  reviewed.  The  display  which 
requests  the  message  ID  is  illustrated  in  Figure  V-19.  After 
acquiring  the  message  ID,  the  requested  message  Is  formatted 
and  displayed  on  the  lower  half  of  the  terminal  screen 
illustrated  in  Figure  V-20.  If  an  invalid  message  ID  is 
supplied,  then  an  error  message,  illustrated  in  Figure  V-21, 
is  returned. 


Figure  V-19.  Message  ID  Request  Display 
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AES-010000 


ANYWHERE 

INCO,  INC.  INTEL.  SIM.  CTR. 
ANY  SUBJECT 
REFERENCES,  IF  ANY 
02  1745  MAY  76 


THIS  IS  A SAMPLE  MESSAGE. 


Figure  V-20.  Message  Review  Display 


e.  Query  a Data  File 

The  query  function  is  used  to  access  queryable  resources 
such  as  data  files.  For  example,  to  query  a file  of  biographic 
information  using  the  functions  menu  in  Figure  V-13,  the 
analyst  enters  ”5”  in  the  "INPUT  DATA"  area  of  the  functions 
menu  display  followed  by  ENTER  DATA.  Once  this  is  accomplished, 
a display  containing  the  name  of  the  resource,  an  input  field 
for  the  ID  of  the  message  which  prompted  the  query,  and  an 
input  field  for  the  actual  data  request  is  sent  to  the  analyst 
station  terminal  screen.  Such  a display  is  illustrated  in 
Figure  V-22.  Once  this  display  is  sent  to  the  terminal 
screen,  the  analyst  must  enter  both  the  pertinent  message  ID 
and  text  indicating  the  type  of  information  he  is  seeking, 
followed  by  ENTER  DATA.  Then,  based  upon  the  message  ID, 
the  resource  is  searched  for  an  appropriate  reply  to  the 
query.  If  no  query  was  anticipated  to  the  chosen  file 
promted  by  the  specified  message,  then  the  analyst  terminal 
screen  receives  a display  stating  that  no  data  are  available. 
Otherwise,  if  a query  reply  is  found,  the  reply  is  formatted 
and  transmitted  to  the  terminal  screen.  Once  ENTER  DATA  is 
struck  following  the  display  of  either  of  these  screens, 
the  function  is  terminated,  and  the  analyst  functions  menu 
is  returned  to  the  screen. 


Figure  V-22.  Sample  Data  File  Query  Display 
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f.  Request  Data  from  a Resource 

The  request  data  function  is  used'  to  access  resources 
which  are  not  queryable  (as  a data  file  is  queryable) . Such 
resources  include  agencies,  commands,  collection  facilities, 
etc.  For  example,  to  request  data  from  the  Collection 
Management  Facility  (CMF)  using  the  functions  menu 
illustrated  in  Figure  V-13,  the  analyst  would  enter  "10"  into 
the  "INPUT  DATA"  field  followed  by  ENTER  DATA.  Once  a request 
function  is  activated,  control  is  passed  to  the  Message  Editor 
for  the  purpose  of  formatting  a message  containing  the  specific 
request.  (see  Section  D for  instructions  on  the  use  of  the 

editor.)  When  control  is  returned  to  the  request  function 
from  the  editor,  the  message  is  examined.  If  the  message 
contains  no  text  then  an  error  display  is  sent  to  the  terminal 
(see  Figure  V-23)  and  the  function  is  terminated.  Otherwise, 
the  message  is  transmitted,  and  the  analyst  station  is 
notified  (see  Figure  V-24) . 


Figure  V-23.  Data  Request  Error  Display 
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YOUR  REQUEST  HAS  BEEN  FORWARDED  TO  THE  PROPER 
SITE  FOR  PROCESSING. 


Figure  V-24.  Data  Request  Termination  Display 


g.  Log  Hard  Copy  References 

This  function  logs  "hard  copy"  (non-automated)  references 
made  by  the  analyst  during  the  exercise.  Using  the  functions 
menu  illustrated  in  Figure  V-13,  the  analyst  would  activate 
this  function  by  entering  "7"  into  the  "INPUT  DATA"  field 
followed  by  ENTER  DATA.  A display  is  returned  to  the  terminal 
screen  which  requests  the  ID  of  the  message  which  prompted 
the  hard  copy  reference,  and  the  reference  material(s)  used. 
This  display  is  illustrated  in  Figure  V-25.  Once  the  analyst 
fills  in  the  two  input  fields  and  strikes  ENTER  DATA,  the 
message  "HARD  COPY  RESOURCE  RECORDED"  is  sent  to  the  terminal 
screen. 
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ACCESS  HARD  COPY  RESOURCE 

MESSAGE  ID  WHICH  PROMPTED  THE  ACCESS: 

AES- 


RESOURCE  USED: 


SECTION  D 
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ON-LINE  MESSAGE  EDITOR  FUNCTIONS 


1.  GENERAL 

a.  Introduction 

The  On-Line  Message  Editor  is  capable  of  modifying  the  header 
and  text  of  existing  messages  as  well  as  constructing  and  editing 
new  messages  entered  from  an  on-line  terminal.  The  editor  is 
modularly  structured  so  that  the  editing  functions  required  for 
each  different  application  can  be  serviced  without  extensive 
modification  to  the  basic  editor.  The  Message  Editor  assumes  that 
all  messages  consist  of  a five  line  header  and  one  or  more  sections 
of  text. 

b.  Access 

The  Message  Editor  is  called  when  required  by  one  of  the  DUP 
Functions,  and  when  called,  displays  a selection  menu  of  Message 
Editor  Functions  as  shown  in  Figure  V-26. 


' 
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MESSAGE 

EDITOR 

• 

/ SELECT  AN  EDITING  OPTION: 

1 

ENTER/REVIEW  THE  MESSAGE 
HEADER 

2. 

REVIEW  THE  CURRENT 
MESSAGE  TEXT 

3. 

ADD  A TEXT  SECTION 

4. 

ADD  A LINE  TO  A SECTION 

5. 

DELETE  A TEXT  SECTION 

6. 

DELETE  A LINE  FROM  A 
SECTION 

7. 

REPLACE  A TEXT  SECTION 

8. 

REPLACE  A LINE  WITHIN 

9. 

TERMINATE  MESSAGE  EDITING 

A SECTION 

INPUT  DATA:  1 

Figure  V-26.  Editor  Functions  Menu 
V-31 


Upon  completion  the  Message  Editor  returns  control  to  the 
tuner  Ion  which  called  it. 

1.1)1  TDK  FUNCTIONS 

a.  Function  1:  Enter /Review  the  Message  Header 

A message  header  consists  of  five  lines:  a "from"  line,  a 

"to"  line,  a "re"  line,  a reference  line,  and  a date/time  group 
line.  When  this  function  is  selected,  a display  is  built  containing 
the  header  of  the  current  message.  The  "from”  line  may  contain 
up  to  72  Characters.  The  "to"  line  may  contain  up  to  60 
characters.  The  "re"  and  reference  lines  may  also  have  up  to 
60  characters,  and  the  date/time  group  line  has  14  characters 
which  may  be  set  up  as  follows: 

DAY  TIME  MONTH  YEAR 
IWHTTTTtfMMMllSYY 

This  syntax  is  not  checked  however. 

Tire  header  may  now  be  altered  as  desired.  Depression  of  the 
ENTER  DATA  key  will  cause  the  altered  header  to  be  stored  and  the 
Message  Editor  selection  menu  will  be  re-displaved . Figure  V-27 
Illustrates  a sample  header  display. 
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b.  Function  2:  Review  the  Current  Message  Text 

This  is  the  counterpart  of  the  Review  Message  Header 
Function,  except  that  no  alteration  of  message  text  can  occur< 
This  function  renumbers  the  text  sections  (in  the  case  of  a 
multi-part  message)  beginning  with  10  and  thereafter  in 
increments  of  10.  Each  text  section  is  displayed  along  with 
the  section  number  as  the  user  pages  through  the  message  by 
use  of  the  appropriate  function  key.  The  ENTER  DATA  key 
returns  the  user  to  the  selection  menu.  Figures  V-28  and 
V-29  illustrate  examples  of  two  possible  responses  to  the 
selection  of  this  function. 


REVIEW  CURRENT  MESSAGE  TEXT 


SECTION  I! 


SECTION  TEXT:  THIS  IS  THE  TEXT  OF  THE  MESSAGE.  ALL 

EXTRANEOUS  INPUT  FIELD  CHARACTERS  WILL  BE  REMOVED  FROM  THE 
TEXT  BY  THE  EDITOR. 


Figure  V-28.  Message  Text  Review  Display 
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REVIEW  CURRENT  MESSAGE  TEXT 


THE  CURRENT  MESSAGE  CONTAINS  NO  TEXT 


Figure  V-29.  Message  Text  Review  - No  Text  Present  Display 


Function  3:  Add  a Text  Section 


When  this  function  Is  selected,  the  display  NEW  SECTION 
NUMBER?  Is  presented.  This  number  must  be  entered  in  order  to 
specify  where  In  the  text  stream  the  new  text  Is  to  go.  When 
this  number  has  been  specified,  the  user  Is  requested  to 
enter  his  new  text.  ENTER  DATA  causes  the  new  text  to  be  stored 


If  a new  section  number  but  no  text  Is  entered,  an  error 
screen  will  be  displayed.  Likewise,  text  with  no  section  number 
will  generate  an  error  message.  If  a message,  through  text  addi- 
tion, grows  too  big  (l.e.,  exceeds  program  buffer  space),  an  error 
message  to  this  effect  trill  be  displayed,  and  the  new  text  will  be 
ignored. 


The  two  samples  illustrated  on  Figure  V-30  partially 
illustrate  the  operation  of  this  function: 


d. 


Function  4:  Add  a Line  to  a Section 
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This  function  will  request  the  Control  Team  user  to  Input: 

o The  80  character  (or  fewer)  line  to  be  added 

o The  number  of  the  section  to  which  the  line  is  to  be 
added 

o The  80  characters  (or  a sufficient  number  to  identify 
the  line)  following  which  the  new  line  Is  to  be  added. 
If  this  field  is  left  blank,  the  new  line  will  be 
inserted  at  the  beginning  of  the  section. 

The  character  string  "/END/"  entered  in  the  "FOLLOWING 
THE  LINE"  input  field  will  cause  the  new  line  to  be  placed 
at  the  end  of  the  section. 

A missing  or  illegal  section  number  trill  generate  an  error 
message,  aa  will  a text  line  for  the  new  line  to  follow  which 
.(O  does  not  exist.  If  the  message  has  grown  too  big,  the  user 

is  informed  and  the  new  line  is  Ignored.  A display  associated 
with  this  function  is  Illustrated  in  Figure  V-31. 
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Function  5:  Delete  • Text  Section 


When  this  function  is  specified,  e display  appears  requesting 
the  section  number  to  be  deleted.  This  display  is  illustrated 
in  Figure  V-32«  When  this  number  is  entered  and  ENTER  DATA 
is  pressed,  the  section  is  deleted  end  the  selection  menu  is 
returned.  A non-existent  section  number  causes  an  error  message. 


DELETE  A TEXT  SECTION 


SECTION  # TO  BE  DELETED 


Figure  V-32.  Delete  e Text  Section  Display 


This  function  will  request  the  Input  of  up  to  80  characters 
of  the  line  to  be  deleted  and  a section  number.  The  Delete  a 

Line  display  is  illustrated  in  Figure  V-33.  When  these  are  I 

entered  and  ENTER  DATA  keyed,  the  line  will  be  located  and 

deleted  and  the  selection  menu  will  be  returned.  Note  that  , 

only  the  first  occurence  of  the  specified  line  will  be  deleted. 

Error  messages  will  be  returned  in  case  of  illegal  text,  an 
illegal  section  number,  or  if  the  line  to  be  deleted  is  not 
found.  Also,  an  informational  message  will  be  returned  if 
the  deletion  of  the  line  causes  the  section  to  be  deleted. 


g.  Function  7:  Replace  « Text  Section 


Upon  selection  of  this  function,  the  user  will  be  requested 
to  enter  the  section  number  of  the  section  to  be  replaced,  and, 
on  the  next  page,  the  replacement  text,  (see  Figure  V-34.) 

Error  messages  will  be  generated  if  the  section  number  is  illegal; 
if  no  text  is  entered;  or  if  the  message,  through  this  replacement 
would  become  too  large. 
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Function  8:  Replace  a Line  within  a Section 


Selection  of  this  function  will  cause  a screen  to  be  displayed 
inviting  the  user  to  enter  the  line  to  be  replaced  (80  Characters 
or  fewer) , the  line  to  replace  it  (80  characters  or  fewer) , and 
either  the  section  number  or  the  word  "ALL"  if  it  is  desired 
that  the  specified  line  be  replaced  in  all  text  sections,  (see 
Figure  V-35.)  Having  done  this  and  having  keyed  ENTER  DATA, 
the  desired  action  will  be  taken.  Note  that  all  occurrences  of 
the  string  to  be  replaced  will  be  replaced,  either  in  a single 
text  section  or  in  the  entire  message. 


Error  displays  will  be  returned  if  the  message  becomes  too 
large,  if  the  text  string  to  be  replaced  cannot  be  found,  or 
if  the  section  number  does  not  exist. 


1. 


Function  9:  Terminate  Message  Editing 


The  selection  of  this  function  followed  by  an  ENTER  DATA  indi- 
cates that  the  user  has  completed  editing  a message.  Control  will 
be  returned  to  the  program  which  called  the  message  editor.  It 
should  be  noted  that  whenever  the  selection  menu  is  displayed  and 
ENTER  DATA  is  pressed  when  no  option  has  been  selected,  the  same 
action  will  occur. 


SECTION  E 

PHYSICAL  CHARACTERISTICS  OF  THE  TEKTRONIX  4010  TERMINAL 


I . GENERAL 

It  is  expected  that  the  initial  use  of  the  Demonstration  Utility 
Prototype  (DUP)  will  be  confined  to  the  Tektronix  4010  Terminal.  Figure 
V-36,  illustrates  the  4010  keyboard,  the  4010  function  keys,  and  their 
operation.  The  following  paragraphs  detail  the  operation  of  those  functions 
keys  crucial  to  the  AIPERS  system  operation. 

J.  FUNCTIONS  RELEVANT  TO  AIPERS 


FUNCTION  KEY  DESIGNATIONS 
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CTRL 
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A 

1 
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ENTER  COMMAND  MODE 

CTRL 
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KSX  CONTROL  INPUT 
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SELECT  OPTION  UNDER  CURSOR  [OR  SEL 9 IF  GIVEN] 
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MOVE  CURSOR  TO  NEXT  S.A. 
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MOVE  CURSOR  TO  PRIOR  INPUT  FIELD 

CTRL 

29 
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254 

MOVE  CURSOR  TO  NEXT  INPUT  FIELD 
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MOVE  CURSOR  TO  S.A.  'HOME* 
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242 

MOVE  CURSOR  DOWN  IN  S.A. 
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33 
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244 

MOVE  CURSOR  RIGHT  IN  S.A. 
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ENTER  DATA 
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CTRL 
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CTRL  '*') 

SHK 

27 
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MOVE  CURSOR  UP  IN  S.A. 

CTRL  ii 

L 

28 

245 

MOVE  CURSOR  LEFT  IN  S.A. 

CTRL  i6 

M 

29 

22 

GRAPHIC  MODE [ FOLLOWED  BY 

FULL  FCHO] 
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N 

30 
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NEXT  PACE  OF  S.A. 

CTRL 

SHO 

31 

0 

ALPHA  MODE [LEAVE  GRAPHIC 

MODE] 

Figure  V-36 


a.  CTRL  A Enter  Command  Mode 

Once  the  exercise  system  software  is  installed,  the  Control 
Team  terminal  screen  will  be  blank  with  the  cursor  positioned  at  the  command 
1 Ine. 

The  Command: 


RUN 


Command 


Program  Name 
Screen  Area 


ECP  T1 


is  entered  from  the  Keyboard.  CTRL  A is  then  entered 
activate  the  command.  This  causes  the  Exercise  Control  Processor  to 


begin  the  exercise. 


to 
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b.  CTRL  C Move  Cursor  to  Next  Screen  Area 

For  the  Control  Team  terminal,  this  key  will  only  be 
needed  to  move  the  cursor  from  the  command  line  to  the  working  screen 
area  after  the  first  display  appears  on  the  screen.  (This  Is  the 
screen  which  requests  exercise  parameter.) 

c.  CTRL  F First  Page  of  display 

CTRL  N Prior  Page  of  display 
CTRL  SH  N Next  Page  of  display 

These  three  function  keys  allow  the  terminal  user  to  page 
back  and  forth  through  multiple-page  displays. 


d.  CTRL  H Move  cursor  to  prior  input  field 

CTRL  I Move  cursor  to  next  input  field 

These  two  keys  are  used  during  the  process  of  entering 
data  into  input  fields  which  are  present  on  die  current  page  of  the 
current  display 


CTRL 

J 

Move 

cursor 

to  Screen  Area 

"HOME" 

CTRL 

K 

Move 

cursor 

down  in  Screen 

Area 

CTRL 

L 

Move 

cursor 

right  in  Screen  Area 

CTRL 

M 

Move 

cursor 

to  first  input 

field  in  next  line 

CTRL 

SH  K 

Move 

cursor 

up  in  Screen  Area 

CTRL 

SH  L 

Move 

cursor 

left  in  Screen 

Area 

The  above  function  keys,  as  well  as  those  on  the  preceding 
pages,  allow  repositioning  of  the  cursor  in  input  fields.  Note  that 
if  no  input  fields  are  present  in  the  screen,  then  these  function  keys 
are  inoperative.  Also  note  that  cursor  positioning  does  not  affect 
data  already  entered  into  input  fields  by  the  terminal  user. 

CTRL  J moves  the  cursor  to  the  first  character  position 
on  the  first  input  field  on  the  current  screen  page. 

CTRL  K and  CTRL  SH  K move  the  cursor  vertically,  down 
and  up,  respectively,  in  the  screen  area.  The  horizontal  position  of  the 
cursor  (its  position  within  the  line)  is  not  affected  unless  the  terminal 
tries  to  move  the  cursor  to  a display-only  field. 

CTRL  M moves  to  the  first  input  field  in  the  next  line. 
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CTRL  I.  and  CTRL  SH  L move  the  cursor  horizontally,  right 
and  left,  respectively,  In  the  screen  area.  The  vertical  position  of 
the  cursor  Is  not  affected. 

f.  CTRL  N Clear  Input  Field 

CTRL  R Rewrite  Screen 

CTRL  N allows  the  terminal  user  to  clear  the  input  field 
in  which  the  cursor  is  positioned,  or  the  current  line  of  the  input 
field  if  the  field  takes  up  more  than  one  line. 

CTRL  R rewrites  the  current  display  with  all  input  fields 
intact.  It  is  useful  for  deleting  extraneous  characters  from  the  screen 

which  have  been  "typed  over." 

g.  CTRL  P 

ENTER  DATA 

ALT  MODE 

Once  input  fields  in  a display  are  filled  in  to  the  terminal 
user's  satisfaction,  either  CTRL  P cr  ALT  MODE  cause  the  data  and  control 
to  be  returned  to  the  processing  program. 

h.  CTRL  C RSX  Control  Input 

CTRL  X RSX  Control  Input 

Both  CTRL  C and  CTRC  X should  be  avoided  at  all  costs. 

They  cause  terminal  control  to  be  returned  to  the  system,  away  from 
TTDL  and  the  exercise. 
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